Avoidance value of Expertise - Page 3 - TankSpot
Remove Advertisements
Avoidance value of Expertise
TankSpot // TankSpot News & Discussion // Theory & Mechanics Discussion
Reply
 
LinkBack Thread Tools
  #41  
Old 10-26-2009, 01:09 PM
Theorydin
WoW Characters
 
Join Date: Mar 2009
Location: Rochester, NY
Posts: 36
So, I took some time to work through the math, and I figured out what's going on. I can now get my analytical result to match yours exactly, but both differ from the result I get with the iterative algorithm. Here's why:

Let's start with your equations. I'll use the notation you used in your spreadsheet, with one minor modification:
Wp = player base weapon speed before parry-haste effects
Wp' = player base weapon speed after parry-haste effects (pWp in spreadsheet)
pph = Wp/Wp' = player parry-haste correction factor
Pp = player parry chance (~20%ish)
A = Extra parry-able attack rate not affected by parry haste (HotR, for example)

Wb = boss base weapon speed pre-parry-haste
Wb' = boss base weapon speed after parry-haste (pWb in spreadsheet)
bph = Wb/Wb' = boss parry-haste correction factor
Pb = boss parry chance (7.5% nominally, i.e. at dodge soft-cap)

Now, let's compare. Starting with your formula for player weapon speed:
1/Wp' = 1/Wp + 0.24*Pp/Wb'

multiplying through by Wp gives a formula for pph:
Wp/Wp' = pph = 1 + 0.24*Wp*Pp/Wb'

In my MATLAB code, the formula for pph is:
pph = 1 + 0.24*Wp'*Pp/Wb'

There's a similar discrepancy in the bph terms. In your analytical formalism:
1/Wb' = 1/Wb + 0.24*Pb*(1/Wp'+A)
bph = Wb/Wb' = 1 + 0.24*Wb*Pb*(1/Wp'+A)

whereas in the matlab code I have (letting player_attack_speed = 1/Wp'+A):
bph = 1 + 0.24*Wb'*Pb*(1/Wp'+A)
I'll come back to the meaning of this discrepancy in a little bit. First, let's do a little math.

If we make some variable substitutions to clean this up a bit, we can put your two equations in a more easily dissectable form:
pph = 1 + Cp*bph
bph = 1 + Cb*(pph + A*Wp)

where Cp = 0.24*Wp*Pp/Wb and Cb = 0.24*Wb*Pb/Wp

This system of equations is clearly solvable, giving the result you use in your spreadsheet. In condensed form, by plugging the second equation into the first and solving for pph, we get:
pph = [ 1 + Cp*(1 + Cb*A*Wp) ] / [ 1 - Cp*Cb]


Let's do the same for my two equations. Using the same substitution, I get these two equations:
pph = 1 + Cp*bph/pph
bph = 1 + Cb*(pph + A*Wp)/bph

These equations are not analytically solvable - let A=0 for simplicity, and you'll see the equations are of the form:
a = 1 + Cp*b/a
b = 1 + Cb*a/b
plugging one into the other doesn't eliminate a variable, and there's no simple way to eliminate either a or b from either equation. At best, you can substitute into the equation for a recursively:
a = 1 + Cp*b/a = 1 + Cp/a*(1+Cb*a/b) = 1 + Cp/a + Cp*Cb/b
= 1 + Cp/a + Cp*Cb/(1+Cb*a/b) = 1 + Cp/a + Cp*Cb/(1+Cb*a/(1+Cb*a/b))
You could make some binomial-type approximations here if Cb*a/b is small, but barring that you can't really get anywhere with them. If you did make that sort of approximation, you'd get terms of alternating sign that increase in powers of (Cb*a). Since this is safely below 1, the series will converge eventually.

On the other hand, these two equations are a recursion relation. By putting in a sample value, you can iterate to arrive at the exact value, provided the set of equations converges. In other words, starting with a0 and b0:

a1 = 1 + Cp*b0/a0
b1 = 1 + Cb*a0/b0

a2 = 1 + Cp*b1/a1
b2 = 1 + Cb*a1/b1

and so on. This is what I do in the MATLAB code, and it's equivalent to extending the series I described out earlier to as many orders as there are iterations.

As a sanity check, your formula gives me pph = 1.0328, while mine gives me pph = 1.02914, a difference of around 0.35%. So as far as accuracy is concerned, either method is more accurate than we'd ever care to worry about.

However, let's quickly address the meaning of the discrepancy, just so we know why the two methods are different. The two formulas for pph were:
pph = 1 + 0.24*Wp*Pp/Wb' (spreadsheet)
pph = 1 + 0.24*Wp'*Pp/Wb' (MATLAB)

The second term here can be interpreted as follows: 24% is the amount of a swing you gain, on average, when you parry an attack. Thus we're multiplying 24% of our weapon speed Wp by the number of parries we get per second on average, as calculated using our parry chance Pp and the boss's parry-adjusted swing timer Wb'.

This makes a lot of sense - we're taking attacks at a rate of 1/Wb', and we parry Pp percent of them, and each parry gives us 24% of a swing. The question is whether we gain 24% of our base (pre-parry-haste) swing speed Wp, or 24% of our parry-hasted swing speed Wp'.

I would guess that the parry-hasted swing speed is the more accurate one, because the goal is to determine how many attacks we get on average during the course of a fight. On the other hand, any individual swing will be parry-hasted by 24% of our pre-parry-haste swing speed. So even I'm not sure which one is the correct answer.

However, as I've shown, the difference comes out to be pretty trivial numerically. Whether we use one version or the other, the answers end up within 1% of each other.

Last edited by theckhd; 10-27-2009 at 08:50 AM.. Reason: fixed some text formatting
Reply With Quote
  #42  
Old 10-26-2009, 01:11 PM
Theorydin
WoW Characters
 
Join Date: Mar 2009
Location: Rochester, NY
Posts: 36
Source: drae
I'm eagerly anticipating that article Theckhd. I've got a couple of questions regarding what kind of impact different levels of ratings have on the final answer, but you'll probably answer them in your article. I'll have to hold my breath.
Ask away, it's entirely possible you'll ask something that I hadn't intended to cover in the article (or hadn't even thought of yet). At worst I'll give you a brief summary of the answer and a "details will be in the article." At best, you might stumble upon something I've overlooked and make the article better for the effort.
Reply With Quote
  #43  
Old 10-26-2009, 03:54 PM
New Registrant
WoW Characters
 
Join Date: Oct 2009
Posts: 7
This makes a lot of sense - we're taking attacks at a rate of 1/Wb', and we parry Pp percent of them, and each parry gives us 24% of a swing. The question is whether we gain 24% of our base (pre-parry-haste) swing speed Wp, or 24% of our parry-hasted swing speed Wp'.

I would guess that the parry-hasted swing speed is the more accurate one, because the goal is to determine how many attacks we get on average during the course of a fight. On the other hand, any individual swing will be parry-hasted by 24% of our pre-parry-haste swing speed. So even I'm not sure which one is the correct answer.
If we take the following statement for granted:
When you parry an attack, the remaining time on your current swing is reduced by 40% of your weapon speed, unless this would result in a reduction to less than 20% of your swing time remaining
This is a rather easy probability-problem, if you draw this problem it would look like:

Where the y-value symbolizes the reduce in weaponspeed and the x values the point in time when the parry occures. The Area under the curves is the average reduce of your swing. (we have a square 0.4*0.4 and a rectangular triangle 0.4*0.4/2 = 0.24) so the haste is based of your normal non-parry-hastened hits. (hopfully this is at least a bit understandibly it would be hard for me to explain it in my first language). If the Boss hits faster than 0.6 your weaponspeed the things might be a bit more complicated (or not) but it is definitly to late for me to think about that
edit: ok the scenario: boss hits faster than 0.6 your weaponspeed wouldn't be that hard but I will have to do some further testing (deadmines I am coming)

Last edited by kahalm; 10-26-2009 at 04:03 PM..
Reply With Quote
  #44  
Old 10-26-2009, 05:14 PM
Theorydin
WoW Characters
 
Join Date: Mar 2009
Location: Rochester, NY
Posts: 36
That's how you calculate the 0.24 in the formulas, but it doesn't answer the question I posed.

Given the statement is correct, we all agree that on an individual swing, you gain up to 40% of your weapon speed Wp.

But we're interested in aggregate statistics - many attacks over a long period of time. In that case, does the formula that uses Wp give a better estimate of the number of attacks, or does the formula with Wp' work better?

Like I said, I can see both arguments. It's possible that the parry-haste term should just use Wp, since that's the amount you would see from a single swing. But that would seem to ignore the recursive form of the equations, in that when you parry, you swing faster, leading to more boss parries, leading to more chances for you to parry, and so forth.

I need to think about it a little harder before I'd feel confident saying one way or the other.
Reply With Quote
  #45  
Old 10-27-2009, 06:49 PM
o_O'
WoW Characters
 
Join Date: Jan 2009
Posts: 61
Source: theckhd
That's how you calculate the 0.24 in the formulas, but it doesn't answer the question I posed.

Given the statement is correct, we all agree that on an individual swing, you gain up to 40% of your weapon speed Wp.

But we're interested in aggregate statistics - many attacks over a long period of time. In that case, does the formula that uses Wp give a better estimate of the number of attacks, or does the formula with Wp' work better?

Like I said, I can see both arguments. It's possible that the parry-haste term should just use Wp, since that's the amount you would see from a single swing. But that would seem to ignore the recursive form of the equations, in that when you parry, you swing faster, leading to more boss parries, leading to more chances for you to parry, and so forth.

I need to think about it a little harder before I'd feel confident saying one way or the other.
I'll start by saying that this does more or less go above my head in terms of math, but here's what I understand we're trying to do:

[1] We're trying to find out how many melee swings we can prevent from happening.
[2] We're trying to find out by how much we can reduce the burst damage taken.

Now as I understand it, you're asking wether for the sake of our swing timer we should plug parry hasted numbers in because if you parry the boss, then your swing timer is reduced, now if the boss parries your parry then his swing timer is reduced, but we might parry that parry (...) etc.

I think that for the sake of question 1, it makes sense to plug hasted numbers. After all it's how things could end up happening on a very rare occasion. And we're looking at how much damage we avoid over a longer period of time.

For the sake of question 2 however, I don't think this is at all relevant. If I just parried a boss's melee swing, then I'm not really taking significant burst damage if my parry causes the boss to parry and last a parry hasted attack. Im not taking burst damage because I just parried the previous attack.

Some other things that I think would matter is how synched up your melee swing is with the boss, and what your swing timer is vs the boss swing timer.

Then again, I could be misunderstanding your dilemma entirely.
Reply With Quote
  #46  
Old 11-03-2009, 12:45 PM
Theorydin
WoW Characters
 
Join Date: Mar 2009
Location: Rochester, NY
Posts: 36
So, I spent some time last week to work this problem out from first principles. It turns out that both expressions are wrong, but for different reasons. Here's the derivation; afterwards I'll explain where kahalm's version of the deriviation went wrong.

There are two ways to interpret the effect of parry-haste. One is to look at a fixed number of swings N. From this point of view, each parry-hasted attack reduces the total time T it takes to reach N swings. In other words, we get N swings in T-dT time, where dT is the total amount of time "saved" via parry-hasting. We can compute the parry-hasted swing rate as:
R = N/(T-dT)
And of course, our swing timer would be the inverse of this, 1/R = (T-dT)/N.

The other way to interpret the effect of parry-haste is to look at a fixed amount of time T. In this formulation, each parry event gives us an additional "fractional swing," because now we're producing swings slightly faster than usual. In other words, we produce N+dN swings in time T, where dN is the sum of all the fractional swings we get from parry-hasting. The swing rate is then calculated as:
R = (N+dN)/T,
with the swing timer again being the inverse of this.

It's important to note that in the long-time limit (T->infinity), (N+dN)/T must approach the same value as N/(T-dT), since they're both perfectly valid ways of calculating the average rate. It was while working through the algebra for these two approaches that I discovered what was happening.

We're going to derive this for a generic system of two events A and B. The problem definition is very simple:
We have events A and B.
Event A happens with frequency Rao (in vacuo)
Event B happens with frequency Rbo (in vacuo).
Event B has a Pb percent chance to decrease the time until the next A by 0.24/Rao.
Event A has a Pa percent chance to decrease the time until the next B by 0.24/Rbo.

Given this well-defined problem, what is the correct analytical answer, or at least the correct set of coupled equations we need to be solving?

Event A will be player auto-attacks, and Event B will be boss auto-attacks. For weapon speed Wao, a player makes N auto-attacks in time T before parry-haste is considered. Thus,
Code:
Rao = N / T = 1 / Wao.
The actual rate of player auto-attacks after parry-haste will be Ra.
In a similar fashion, Wbo is the base boss weapon speed Rbo is the base boss attack rate, and Rb is the rate after parry-haste.

(Note: The nomenclature here is partly blizzard's fault. They call it "weapon speed," but then give a value in seconds. Anyone with a basic science background knows that a speed is a rate, and should be in units of 1/s. Nonetheless, I'm going to stick with their convention of calling Wao and Wbo "speeds" but using units of seconds. Hopefully this isn't too confusing, since I'll be attempting to use Rao and Rbo rather than Wao or Wbo wherever possible.)

We'll now calculate the average Ra with each approach to make sure they agree:

In time period T, we'd have T.*Pb.*Rb parries. Each parry reduces the swing timer by 0.24*Wao seconds. We're sure this is correct, because on a successful parry the swing timer is reduced by 40% of the pre-parry-haste value Wao, not the post-parry-haste value Wa. In other words, whether or not your previous attack was parry-hasted has no effect on the reduction (in seconds) you get during your next swing. This is consistent with the old EJ parryhaste mechanics thread, and there will be further proof later in the derivation that using 0.24*Wa gives you an incorrect answer.

This leads to a cumulative time reduction dT:
Code:
dT = 0.24*Wao*T*Pb*Rb
Just to check that this makes sense, this is:
Code:
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)
I'm going to define a constant c = 0.24*Pb to simplify the rest of the derivation, such that
Code:
dT = c*T*Rb*Wao.


First Approach
:
We have N attacks in time (T-dT), for a rate of:
Code:
Ra = N / (T-dT) = (T*Rao)/(T - c*T*Rb*Wao) = Rao/(1-c*Rb*Wao)
Ra*(1-c*Rb*Wao) = Rao
Ra = Rao + c*Rb*Ra/Rao 
Note that this differs from both the version we use in the MATLAB (which is Ra = Rao + c*Rb*Rao/Ra given that pph=Wao/Wa=Ra/Rao) as well as kahalm's version (Ra = Rao + c*Rb). I'll come back to that point in a second.

Second Approach:
The other approach is to say that in time T, we actually get N + dN attacks due to parry haste. N is still T*Rao, but since it only takes (T - dT) to the Nth attack, there's some time left over (dT) during which we can sneak in dN extra attacks. The average rate is then Ra=(N + dN)/T.

This is a crucial juncture, because there's a "wrong way" and a "right way" to calculate dN. I will now demonstrate that by doing it the "wrong way" you get kahalm's answer, and by doing it the "right way" you get an answer consistent with the previous N/(T-dT) formulation that you suggested.

Wrong Way: In time dT, you get dN = dT/Wao = dT*Rao extra attacks. Then
Code:
Ra = (N + dN)/T = (T/Wao + dT/Wao)/T 
   = (T*Rao + c*T*Rb*Wao/Wao)/T = Rao + c*Rb
Ra = Rao + c*Rb
This is exactly the form that kahlam's equations take.

Right Way: In time dT, you actually get dN = dT/Wa = dT*Ra extra attacks. The justification is very straightforward: There's nothing "special" about that period dT that would prevent us from seeing parry-hasting. Since dN represents the total number of attacks we generate in dT (including the effects of parry-haste), we have to use the rate Ra. This is no different from saying that over a 5-minute fight, we'd expect 5*60*Ra parry-able attacks. Thus:
Code:
Ra = (N + dN)/T = (T/Wao + c*T*Rb*Wao/Wa)/T 
   = Rao + c*Rb*Ra/Rao
which agrees with the N/(T-dT) formulation.

I'll note here that if you make an error calculating dT, specifically by using Wa instead of Wao, the N/(T-dT) formulation also gives you kahlam's answer, Ra = Rao + c*Rb. This is the proof I mentioned up when I defined dT. If you use Wa to define dT, the two averages don't come out in agreement, which they must if they are to have any physical meaning.

To summarize, here are the three possible forms of Ra that we have:
Code:
Ra = Rao + c*Rb*Ra/Rao (derived from first principles two different ways)
Ra = Rao + c*Rb  (kahlam's - caused by an error in the above derivation)
Ra = Rao + c*Rb*Rao/Ra (MATLAB)
The version I've derived here from first principles is correct.

Kahlam's, while wrong, is the closest to correct. It's error is simply a factor of (Rao/Ra) in the coupling term, and it's arrived at by making a minor mistake in the derivation. It's also worth noting here that this is effectively a first-order approximation, since he's substituted Wao in a spot where Wa should have been.
Note that the result of this is to slightly over-couple the equation, since (Rao/Ra > 1)

The MATLAB version is the farthest off. It differs by a factor of (Rao/Ra)^2, thus over-coupling more than kahlam's version. Furthermore, I haven't found any sort of rational justification for this factor. The closest I can come is by making two consecutive mistakes in the derivation: first by calculating dT as c*T*Rb*Wa, followed by calculating dN as dT/Wao. Those two errors are mutually inconsistent, so there's no chance that this is actually a lucky string of errors that corrects themselves. My best guess is that when we were fooling around with the parry-haste code, I either made a typo or we were trying to do something unnecessarily complicated to account for higher-order parry effects (i.e. two parries within one swing timer).

One can perform a similar calculation for Rb to get the complete system of equations that need to be solved. They are:

Code:
Ra = Rao + c1*Rb*(Ra/Rao)
Rb = Rbo + c2*Raa*(Rb/Rbo)
Raa = f(Ra) = A + B*Ra
where A is the static term representing attacks that are independent of parry haste (33/6 for warriors, for example) and B is the contribution from attacks that benefit from parry-haste (1 for warriors).

As a final thought, it should be noted that these equations are not as simple to solve as the ones kahalm came up, but they are solvable. Here's the derivation:

Code:
Starting from:
Ra = Rao + c1*Rb*Ra/Rao
Rb = Rbo + c2*Raa*Rb/Rbo
Raa = A + B*Ra

Solve Rb eqn for Rb:
Rb(1-c2*Raa/Rbo)=Rbo
Rb = Rbo/(1-c2*Raa/Rbo)

Plug into Ra eqn:
Ra - Rao = (c1*Ra/Rao)*Rbo/(1-c2*Raa/Rbo) = (c1*Ra/Rao)*Rbo^2/(Rbo - c2*Raa)
(Ra - Rao)*(Rbo - c2*Raa) = c1*Ra*Rbo^2/Rao
Ra*Rbo - c2*Ra*Raa - Rao*Rbo + c2*Raa*Rao - c1*Ra*Rbo^2/Rao = 0
-Ra*Rbo + c2*Ra*(A+B*Ra) + Rao*Rbo - c2*Rao*(A+B*Ra) - c1*Ra*Rbo^2/Rao = 0
c2*B*Ra^2 + (c2*A + c1*Rbo^2/Rao - Rbo - c2*B*Rao)*Ra + (Rao*Rbo-c2*A*Rao) = 0

let:
a=c2*B
b=(c2*A + c1*Rbo^2/Rao - Rbo - c2*B*Rao)
c=Rao*Rbo - c2*A*Rao

and we have a standard quadratic equation:
a*Ra^2 + b*Ra + c = 0

The solution is then
Ra=(-b - sqrt(b^2-4*a*c))/(2*a)
where I've chosen the negative root of the square since it gives a realistic result
(the positive root gives us something ridiculous like 13 attacks per second).
Some quick testing shows that my iterative technique gives me the same result as the analytical solution out to 8 decimal places.


I've already updated my local version of the code to reflect this model. I'm in the process of nailing down the particular values of A and B for each class (and possibly another constant C for DK's courtesy of the way Rune Strike interacts with boss attacks). Once that's done, I should easily be able to calculate efficiency values for each of the four classes, and thus get around to completing the article.
Reply With Quote
  #47  
Old 11-03-2009, 01:05 PM
GravityDK's Avatar
Death Knight and sponsor
WoW Characters
 
Join Date: Nov 2008
Location: UK
Posts: 244
That, Theckhd, would be a superb achievement. Thanks for your efforts so far!
__________________
My blog on tanking, thinking and leadership at pwnwear.com.
Reply With Quote
Reply

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are On


World of Warcraft™ and Blizzard Entertainment® are all trademarks or registered trademarks of Blizzard Entertainment in the United States and/or other countries. These terms and all related materials, logos, and images are copyright © Blizzard Entertainment. This site is in no way associated with or endorsed by Blizzard Entertainment®.