Elitist Jerks (http://elitistjerks.com/forums.php)
-   Class Mechanics (http://elitistjerks.com/f31/)
-   -   [Math] Stat Equivalence in Multi-ability "Rotations" (http://elitistjerks.com/f31/t22891-math_stat_equivalence_multi_ability_rotations/)

Muphrid  03/12/08 10:19 AM

[Math] Stat Equivalence in Multi-ability "Rotations"

It is fairly straightforward to theorycraft the equivalence of stats for a given ability. Variables that don't change often cancel out nicely, yielding a clean, concise result. This post will extend those general methods to multi-ability "rotations" (which, in fact, need not be periodic at all).

The Absolute Difference Formulation

Let us consider an abstract objective function $F$ that is a function of stats and abilities represented by a vector $\vec u$. That is, we're considering the effects of different stats on the value of $F(\vec u)$. Any change in stats or circumstances can be expressed as $\Delta \vec u$ and the magnitude of the effect of that change given by $F(\vec u + \Delta \vec u) - F(\vec u)= \Delta F(\vec u, \Delta \vec u)$. For brevity, I'll abbreviate this as $\Delta F_u$.

For some combination of abilities used, we have...

$F= n_1 F_1 + n_2 F_2 + \cdots + n_k F_k = \sum_{j=1}^k n_j F_j = \vec n \cdot \vec F$

...where $n_k$ is a weighting constant. The meaning of $n_k$ can vary based on the problem: in a calculation of just raw damage for the whole rotation or sequence, $n_k$ represents the number of times the kth ability is used. In a calculation of overall DPS, it would represent the proportion of time spent using the kth ability.

Due to the linearity of the problem, we can conclude that $\Delta F_u= \vec n \cdot \Delta \vec F_u$. Ultimately, what we want to do is substitute some expression $\vec f(\Delta u)= \Delta \vec F_u$. The most convenient case is when $\vec f(\Delta u)= \Delta u \vec \kappa = \Delta \vec F_u$, where $\vec \kappa$ is a constant vector. This is the linear case, where the stat has no quadratic or higher-order effects on the objective function. In practice, for sufficiently small stat changes, we can approximate the problem as completely linear without much loss of precision.

Now then, what we ultimately have is $\Delta F_u= \Delta u ( \vec n \cdot \vec \kappa_u )$. If we consider some other possible stat change $\Delta \vec v$, that would look like $\Delta F_v= \Delta v ( \vec n \cdot \vec \kappa_v )$. The whole idea of stat equivalence is that we set $\Delta F_u= \Delta F_v$, which leads us to...

$\Delta u (\vec n \cdot \vec \kappa_u)= \Delta v (\vec n \cdot \vec \kappa_v) \Rightarrow \Delta u = \frac{\vec n \cdot \vec \kappa_v}{\vec n \cdot \vec \kappa_u} \Delta v$

It behooves us, for the moment, to go back to the one-ability case. In this case, we deal with not vectors but constants: $\Delta u= \frac{n \kappa_v}{n \kappa_u} \Delta v = \frac{\kappa_v}{\kappa_u} \Delta v$. A good result: it means that the constants we're using are based on the one-ability case.

The Relative Difference Formulation

It's also useful to consider $\frac{\Delta F_u}{F}= \nabla F_u$, the reative difference instead of just the absolute difference (I use the nabla symbol to denote this, though that's much less standard than the delta for the absolute difference, and it risks confusion with the gradient). We have...

$\nabla F_u= \frac{\Delta F_u}{F} = \frac{\vec n \cdot \Delta \vec F_u}{\vec n \cdot \vec F_u} = \nabla \vec F_u \cdot \vec N$

...where $\vec N= (n_1 F_1, n_2 F_2, \cdots, n_k F_k)/(\vec n \cdot \vec F)$

The advantage of this approach is that $\vec N$ has a special meaning: the kth element of this vector is the proportion of $F$ contributed by $n_k F_k$, or by the kth ability in the "rotation" or sequence. For example, if we're dealing in expected damage or DPS functions, this value would be equal to the proportion of total damage done by a given ability, which is something you could obtain without calculation but from a wws parse.

As before, we can approximate $\nabla F_u$ as linear, meaning $\nabla \vec F_u= \Delta u \vec K_u$. Thus, we now have a different version of our expression for stat equivalence:

$\Delta u (\vec N \cdot \vec K_u)= \Delta v (\vec N \cdot \vec K_v) \Rightarrow \Delta u = \frac{\vec N \cdot \vec K_v}{\vec N \cdot \vec K_u} \Delta v$

An Example: +spell power vs. +spell crit

At this point, it's easy to get lost in the notation or the formulas, so I'll provide a concrete example: let's consider an Arcane/Frost mage (I choose this example for simplicity; more common Fire builds have problems with Ignite when considering practical application of this procedure--more general problems involving 3+ abilities or the damage of a melee class would be that much more cumbersome).

We'll assume that this mage uses Arcane Blast and Frostbolt, with Arcane Blast being 69% of the damage done and Frostbolt 31%. Let AB have a 41% crit rate, Frostbolt 40%. Assume 1400 +damage on average. Let's examine the equivalence between +damage and +crit.

Obviously, $\vec N= (.69, .31)$ (order is not relevant, as long as we're consistent). Note that, in general...

$K_{d,k}= \frac{1}{\frac{m_k}{r_k} + d_k}$

...where m = average base damage, r = +damage coefficient, and d = +damage. m = 700 ish for AB, r = .714. m = 623.5 ish for Frostbolt, and r = .814. d = 1400 for both. Using these values, we get $\vec K_d= (4.20, 4.62)\cdot 10^{-4}$.

In general...

$K_{c,k}= \frac{1}{\frac{1}{b_k} + c_k}$

Where b is the crit bonus and c the crit chance. b = .75 for AB, 1.25 for an Arc/Frost Frostbolt. c was given to us above. $\vec K_c= (.574, .833)$.

$1 \mbox{ spell crit rating } \equiv \frac{\vec N \cdot \vec K_c}{\vec N \cdot \vec K_d} \frac{1}{2208}= \frac{.654}{.000433} \frac{1}{2208} = .684 \mbox{ +damage}$

Which is a fairly sensible result.

Application with WWS?

When I started to tackle the problem of multi-ability equivalences, I doubted there would be any practical application to the math behind it. However, I knew it would be interesting to start with the expressions for relative differences, as the percentage of one's damage or DPS from a given spell or ability could be easily estimated by a damage meter or WWS. WWS, of course, has its share of problems: any given boss fight constitutes a somewhat small sample size, which means big error bars (even larger still since we can't know one's average spell damage or attack power directly like we can with crit chances).

To be entirely truthful, though, the only power this has is in how WWS hands you $\vec N$ on a silver platter. I'm certain that this can be useful, but I'm unsure quite how useful it will turn out to be. In short, I suppose it depends largely on whether it makes sense to use WWS as an estimate of average parameters, given the variance inherent to those estimates.

alienangel  03/12/08 4:59 PM

I think I lost you a bit in the calculation of actual values for K in the example :S

Regarding using WWS to obtain the N values, yes, WWS seems a bit dubious for that, since I know my damage proportions vary a fair bit from night to night based on random crit rates/miss rates/debuffs/heroism timing etc, so it's still not really handing N to us "on a silver platter". Obtaining N from a simulation would be better, but if we're at the point of having a simulation worth trusting we can work out stat equivalences iteratively instead of analytically anyway :S

Regardless, interesting work :) I'm impressed at the quality of the notation too, is that actually a feature provided by the forums? Time to experiment with the code shown in the tooltips for the images :)

Muphrid  03/12/08 5:07 PM

Quote:

Originally Posted by alienangel 					(Post 672955) 				 				I think I lost you a bit in the calculation of actual values for K in the example :S
Sorry about that; those expressions for each K are based on a simple expected damage/cast formula:

$E= hq(m+rd)(1+bc)$

From here, you can see that...

$\Delta E_d= hq(1+bc)r \Delta d \Rightarrow \frac{\Delta E_d}{E} = \frac{r \Delta d}{m+rd} = \frac{\Delta d}{\frac{m}{r}+d}$

Which makes it somewhat clear where I got the expression for K_d from. Similar logic gets you K_c.

Quote:

Regarding using WWS to obtain the N values, yes, WWS seems a bit dubious for that, since I know my damage proportions vary a fair bit from night to night based on random crit rates/miss rates/debuffs/heroism timing etc, so it's still not really handing N to us "on a silver platter". Obtaining N from a simulation would be better, but if we're at the point of having a simulation worth trusting we can work out stat equivalences iteratively instead of analytically anyway :S
You're right, of course. This analysis has, however, motivated me to brush up on statistics and see whether it would be worthwhile to approach this not as an exact calculation but an estimate with the appropriate error bars.

Quote:

Regardless, interesting work :) I'm impressed at the quality of the notation too, is that actually a feature provided by the forums? Time to experiment with the code shown in the tooltips for the images :)
The forums themselves have $\LaTeX$ built in; I've found it a good way to be clear with symbolic math and practice at the same time.

Kavan  03/12/08 7:26 PM

Another thing to consider is also that N is not an independent variable, but depends on stats. This is specially true for arcane builds where exactly how long a fight is or how much mana you have will determine the weights of each cycle. I guess for first order approximation these can be neglected, but they definitely play a role.

Muphrid  03/12/08 8:27 PM

Quote:

Originally Posted by Kavan 					(Post 673124) 				 				Another thing to consider is also that N is not an independent variable, but depends on stats. This is specially true for arcane builds where exactly how long a fight is or how much mana you have will determine the weights of each cycle. I guess for first order approximation these can be neglected, but they definitely play a role.
Oh yes, it's only the meaning of N that is convenient; it is by no means a constant, and closed-form expressions for its components will not be pretty.

I would say that the first-order approximation means that the effect of stats on what your overall rotation is is negligible, yeah, just because we're dealing with small stat changes.

alienangel  03/12/08 9:04 PM

Quote:

Originally Posted by Muphrid 					(Post 673178) 				 				Oh yes, it's only the meaning of N that is convenient; it is by no means a constant, and closed-form expressions for its components will not be pretty.  I would say that the first-order approximation means that the effect of stats on what your overall rotation is is negligible, yeah, just because we're dealing with small stat changes.
In WoW terms this isn't necessarily the case though. A difference of a few haste rating can (in theory anyway) change the ratio of specials to autoattacks quite dramatically for classes whose specials interfere with their autoattacks, which tends to have a larger effect on N values than just changing things like crit/hit/+dmg. The hunter threads are currently a depressing and painful mess trying to sort this kind of thing out.

Kamma  03/13/08 3:01 AM

I think it would be useful to take a step back from $N$ by using specific dmg functions for each ability to transform it to a vector representing the probability of using each ability - ie normalizing it to the proportion that a spell is used, not the proportion of damage done by the spell.

This would useful in making more accurate extrapolations. Just a thought.

Muphrid  03/13/08 12:53 PM

Proportion that a spell is used in terms of time? Using DPS per casting time, you can do this with the absolute difference approach.

Hm, I have a hunch that you could probably do it with the relative differences as well, but that's going to take some thought.

All times are GMT -4. The time now is 4:39 PM.

Forum Infrastructure by vBulletin 3.6.12 ©2000-2007, Jelsoft Enterprises Ltd.
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 0, "mathjax_display_tex": 0, "mathjax_asciimath": 0, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 40}, "config": {"markdown_headings": false, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 20, "end_threshold": 15, "enable": true}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "github"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "english_confidence": 0.9413500428199768, "perplexity_flag": "middle"}