A Call to Arms  MoP Mechanics Testing
Moderators: Fridmarr, Worldie, Aergis, theckhd
Re: A Call to Arms  MoP Mechanics Testing
That addon is dynamite. I just generated a quick data set using my prot and ret gear, and got the following results:
Curiously, I get a slightly better fit if I allow the str>parry conversion factor to vary:
Now, it's not curious that the fit gets better  more degrees of freedom will do that. But I noticed this gives me a C that matches the warrior version. How sure are we that a is identically 243.6?
Also, I've written a quick MATLAB function that extracts the data from a chat log produced by the addon. If I could convince a bunch of people to install the addon, follow the instructions to generate a chat log, and send me their text files, we can generate a truly massive amount of data and nail these values down very accurately.
 Code: Select all
General model:
f(x,y) = 3+164./243.6+1/(1/C+0.885/(y+(x164)./243.6))
Coefficients (with 95% confidence bounds):
C = 235.1 (235, 235.2)
Goodness of fit:
SSE: 0.0006873
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.00431
Curiously, I get a slightly better fit if I allow the str>parry conversion factor to vary:
 Code: Select all
General model:
f(x,y) = 3+164./a+1/(1/C+0.885/(y+(x164)./a))
Coefficients (with 95% confidence bounds):
C = 237.5 (237, 238)
a = 243.9 (243.9, 244)
Goodness of fit:
SSE: 0.0001621
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.002122
Now, it's not curious that the fit gets better  more degrees of freedom will do that. But I noticed this gives me a C that matches the warrior version. How sure are we that a is identically 243.6?
Also, I've written a quick MATLAB function that extracts the data from a chat log produced by the addon. If I could convince a bunch of people to install the addon, follow the instructions to generate a chat log, and send me their text files, we can generate a truly massive amount of data and nail these values down very accurately.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of GrehnSkipjack.
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty

theckhd  Moderator
 Posts: 7955
 Joined: Thu Jul 31, 2008 3:06 pm
 Location: Harrisburg, PA
Re: A Call to Arms  MoP Mechanics Testing
I should have made it at the start of beta, took 30 minutes perhaps, and a breeze instead of a bother now. The added significant figures and reduced chance of typo's is a benefit as well.
More data would be lovely, the addon does not check for duplicate entries, as multiple datasets still might give you those, so this has to be filtered out post process.
I still want to believe that the Cp's to be the same
On a side note, I remember in early beta that Paladin and Warrior values where matching, does anybody remember when they changed? My guess would be when Blizzard decided that Shield Block would block everything for 6 seconds. I would just love to know their motivation behind the numbers.
More data would be lovely, the addon does not check for duplicate entries, as multiple datasets still might give you those, so this has to be filtered out post process.
I still want to believe that the Cp's to be the same
On a side note, I remember in early beta that Paladin and Warrior values where matching, does anybody remember when they changed? My guess would be when Blizzard decided that Shield Block would block everything for 6 seconds. I would just love to know their motivation behind the numbers.
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
I updated statslog to also include player class and level to make it easier for mass processing.
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
Does your addon detects when stats are modified by a buff ?
Thanks for your work
Thanks for your work
 NinJOu
 Posts: 5
 Joined: Wed Feb 03, 2010 3:26 am
Re: A Call to Arms  MoP Mechanics Testing
No it does not. In that case you can manually call /printstats.
I might add it in later, it requires keeping track of all your combat stats.
I might add it in later, it requires keeping track of all your combat stats.
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
mythor wrote:I still want to believe that the Cp's to be the same
On a side note, I remember in early beta that Paladin and Warrior values where matching, does anybody remember when they changed? My guess would be when Blizzard decided that Shield Block would block everything for 6 seconds. I would just love to know their motivation behind the numbers.
I'll take a look at some more paladin data and see if I can convince myself that I'm underestimating, but I doubt it.
I forget exactly when the equations changed, but I think it was around the same time as the Vengeance changes were implemented. It could have been earlier, though, and we just didn't notice it until then.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of GrehnSkipjack.
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty

theckhd  Moderator
 Posts: 7955
 Joined: Thu Jul 31, 2008 3:06 pm
 Location: Harrisburg, PA
Re: A Call to Arms  MoP Mechanics Testing
Taking this data set provided by Pauladin, I think I can make fairly solid statements about our DR equations. Mythor will be pleased.
Parry fit (using x=strbaseStr, y=preParry):
Dodge fit (using x=preDodge):
Block fit, excluding two obviously errant data points caused by ret paladins (low by exactly 10%):
Comments:
1) Our estimate of k=0.885 was slightly off, probably due to a lack of solid data (all previous data sets used rounded values, which limited our accuracy). The consistency of k between all three fits is just too hard to ignore. Most importantly, the parry fit is extremely good; none of the residuals are larger than 0.000005, or 5E6. The parry fit alone is enough to convince me of k and Cp, both because of the sheer quality of the fit and because it predicts a correctly.
2) The fitted Cp value is fairly consistent with the warrior one. Given how good a fit we have, I suspect that Cp=237.2 for both warriors and paladins.
3) The dodge cap isn't exactly the same as Cataclysm. If I fix the doge cap to the Cata value, I get this fit:
While that's good, it's not as good as the one where we allow C to vary, nor is the k value consistent with the incredible parry fit we have. If I force k=0.884 in the parry fit, I get this:
We already know that this value of a is blatantly wrong, and the RMSE gets almost 4 orders of magnitude worse. Furthermore, the residual errors now include values as high as 0.006, or 6E3, large enough to cause demonstrable rounding errors on the tooltip.
If we instead assume that k=0.886, I get this fit for dodge:
As much as I really, really think it makes sense logically that the dodge cap is the same as the Cata version, I feel like the data just doesn't support it anymore. I can't fathom a guess at why it changed by ~0.9, but it seems to have.
4) Block's cap is slightly altered based on the new value of k; this is also more consistent with the estimates I've seen from warrior data. Fixing k gives us a very clear value:
Conclusions:
I think our new best estimates for the following constants are:
k=0.886
Cp=237.20
Cd=66.56
Cb=150.40
Parry fit (using x=strbaseStr, y=preParry):
 Code: Select all
General model:
f(x,y) = 3+164./a+1./(1/C+k./(y+x./a))
Coefficients (with 95% confidence bounds):
C = 237.2 (237.2, 237.2)
a = 243.6 (243.6, 243.6)
k = 0.886 (0.886, 0.886)
Goodness of fit:
SSE: 7.574e011
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 7.13e007
Dodge fit (using x=preDodge):
 Code: Select all
General model:
f(x) = 2+3.01+1/(1/C+k/x)
Coefficients (with 95% confidence bounds):
C = 66.55 (66.41, 66.69)
k = 0.886 (0.8856, 0.8863)
Goodness of fit:
SSE: 0.003583
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.004888
Block fit, excluding two obviously errant data points caused by ret paladins (low by exactly 10%):
 Code: Select all
General model:
f(x) = 13+1/(1/C+k/x)
Coefficients (with 95% confidence bounds):
C = 150.4 (150.3, 150.5)
k = 0.886 (0.8859, 0.8861)
Goodness of fit:
SSE: 0.0005365
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.001904
Comments:
1) Our estimate of k=0.885 was slightly off, probably due to a lack of solid data (all previous data sets used rounded values, which limited our accuracy). The consistency of k between all three fits is just too hard to ignore. Most importantly, the parry fit is extremely good; none of the residuals are larger than 0.000005, or 5E6. The parry fit alone is enough to convince me of k and Cp, both because of the sheer quality of the fit and because it predicts a correctly.
2) The fitted Cp value is fairly consistent with the warrior one. Given how good a fit we have, I suspect that Cp=237.2 for both warriors and paladins.
3) The dodge cap isn't exactly the same as Cataclysm. If I fix the doge cap to the Cata value, I get this fit:
 Code: Select all
General model:
f(x) = 2+3.01+1/(1/65.631440+k/x)
Coefficients (with 95% confidence bounds):
k = 0.8839 (0.8837, 0.8841)
Goodness of fit:
SSE: 0.007511
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.007053
While that's good, it's not as good as the one where we allow C to vary, nor is the k value consistent with the incredible parry fit we have. If I force k=0.884 in the parry fit, I get this:
 Code: Select all
General model:
f(x,y) = 3+164./a+1./(1/C+0.884./(y+x./a))
Coefficients (with 95% confidence bounds):
C = 235.8 (235.6, 236)
a = 244.1 (244.1, 244.2)
Goodness of fit:
SSE: 0.0007984
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.002307
We already know that this value of a is blatantly wrong, and the RMSE gets almost 4 orders of magnitude worse. Furthermore, the residual errors now include values as high as 0.006, or 6E3, large enough to cause demonstrable rounding errors on the tooltip.
If we instead assume that k=0.886, I get this fit for dodge:
 Code: Select all
General model:
f(x) = 2+3.01+1/(1/C+0.886/x)
Coefficients (with 95% confidence bounds):
C = 66.56 (66.5, 66.61)
Goodness of fit:
SSE: 0.003584
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.004872
As much as I really, really think it makes sense logically that the dodge cap is the same as the Cata version, I feel like the data just doesn't support it anymore. I can't fathom a guess at why it changed by ~0.9, but it seems to have.
4) Block's cap is slightly altered based on the new value of k; this is also more consistent with the estimates I've seen from warrior data. Fixing k gives us a very clear value:
 Code: Select all
General model:
f(x) = 13+1/(1/C+0.886/x)
Coefficients (with 95% confidence bounds):
C = 150.4 (150.4, 150.4)
Goodness of fit:
SSE: 0.0005367
Rsquare: 1
Adjusted Rsquare: 1
RMSE: 0.001898
Conclusions:
I think our new best estimates for the following constants are:
k=0.886
Cp=237.20
Cd=66.56
Cb=150.40
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of GrehnSkipjack.
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty

theckhd  Moderator
 Posts: 7955
 Joined: Thu Jul 31, 2008 3:06 pm
 Location: Harrisburg, PA
Re: A Call to Arms  MoP Mechanics Testing
You guys rule, My addon is getting more and more accurate by the day.
This is what I have currently for level 90:
Paladin:
Warrior:
Did I get the wrong values for anything?
<Edit>
Also are base stats (Str & Stam in this case) independent of Class? If not then Ill have to come up with a better solution for my tables.
This is what I have currently for level 90:
Paladin:
 Code: Select all
k = .886
c_D = 66.56
c_P = 237.2
c_B = 150.4
Strength Scalar = 951.16
Mastery Scalar = 600
Block Scalar = 1
Warrior:
 Code: Select all
k = .956
c_D = 91.03
c_P = 237.2
c_B = 150.4
Strength Scalar = 951.16
Mastery Scalar = 272.6
Block Scalar = (.5/2.2) = .227272
Did I get the wrong values for anything?
<Edit>
Also are base stats (Str & Stam in this case) independent of Class? If not then Ill have to come up with a better solution for my tables.
 xstratax
 Maintankadonor
 Posts: 118
 Joined: Fri Aug 14, 2009 1:18 pm
Re: A Call to Arms  MoP Mechanics Testing
I'm pretty sure base stats vary by class. My notes have 164 str for a L85 paladin and 189 str for a L85 warrior.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of GrehnSkipjack.
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty

theckhd  Moderator
 Posts: 7955
 Joined: Thu Jul 31, 2008 3:06 pm
 Location: Harrisburg, PA
Re: A Call to Arms  MoP Mechanics Testing
Well crud...so much for the simple solution. Now I have to find a list of values for the various races per Warrior, thankfully your spreadsheet covers Paladin values already.
 xstratax
 Maintankadonor
 Posts: 118
 Joined: Fri Aug 14, 2009 1:18 pm
Re: A Call to Arms  MoP Mechanics Testing
Early Christmas!
I have to agree that it does not sit well with me that Cp_pala changed, but the data can't be lying.
One guess is that they redid some of their root calculations to make it work for all classes including monks, and just took the nearest cata value for paladins. (isn't guessing fun).
5E6 I can live with, nice work
xstratax the mastery scalar still needs a checkup, i'll try to do that soonish.
I have to agree that it does not sit well with me that Cp_pala changed, but the data can't be lying.
One guess is that they redid some of their root calculations to make it work for all classes including monks, and just took the nearest cata value for paladins. (isn't guessing fun).
5E6 I can live with, nice work
xstratax the mastery scalar still needs a checkup, i'll try to do that soonish.
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
Changed statslog to now include the total mastery value instead of the bonus effect (apparently mastery had it own special function for that). And put on some PvP gear to get nice mastery values.
The result:
272.7272 mastery rating is 1% mastery.
Base mastery = 4800 (The 17.6 you see on your char pane when naked)
Data: https://docs.google.com/spreadsheet/ccc ... tcWc#gid=2
The result:
272.7272 mastery rating is 1% mastery.
Base mastery = 4800 (The 17.6 you see on your char pane when naked)
Data: https://docs.google.com/spreadsheet/ccc ... tcWc#gid=2
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
Ignore this post.
Pro tip: Don't do stuff while sleeping.
Pro tip: Don't do stuff while sleeping.
Last edited by mythor on Thu Sep 13, 2012 5:28 am, edited 1 time in total.
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Re: A Call to Arms  MoP Mechanics Testing
mythor wrote:The result:
272.7272 mastery rating is 1% mastery.
I hope I am not the only one who finds it...humorous(Lack of a better word) that this would be the current mastery per 1% for Crit Block when (.5/2.2) = 0.227272 is the Block per 1% mastery...sorry I find the repeating 2s and 7s oddly amusing for some strange reason
 xstratax
 Maintankadonor
 Posts: 118
 Joined: Fri Aug 14, 2009 1:18 pm
Re: A Call to Arms  MoP Mechanics Testing
Statslog contained a serious error, wow API does not update values it has to calculate it self on all triggers.
This means that when you changed a piece of gear, asking the API for a block value or mastery effect value, it could still return the old value. Even after a delay it sometimes did this. I am not sure if this is calculated in another thread but I do know that the current approach can not be trusted. I disabled the automatic reporting on item change and you now have to call it manual. This seems to return correct values all the time.
This also means my previous dataset for mastery testing was wrong and I have updated those with new correct values.
Using these new values for warrior block scaling with the comments of the blog in mind and the new found C.
Plugging in the plausible scaling factor.
This means that when you changed a piece of gear, asking the API for a block value or mastery effect value, it could still return the old value. Even after a delay it sometimes did this. I am not sure if this is calculated in another thread but I do know that the current approach can not be trusted. I disabled the automatic reporting on item change and you now have to call it manual. This seems to return correct values all the time.
This also means my previous dataset for mastery testing was wrong and I have updated those with new correct values.
Using these new values for warrior block scaling with the comments of the blog in mind and the new found C.
 Code: Select all
General model:
mast_fit(x) = 13 + 1 / (1 / 150.4 + 0.956 / (x * a))
Coefficients (with 95% confidence bounds):
a = 0.227 (0.2263, 0.2276)
mast_fit_GoF =
sse: 0.1106
rsquare: 0.9988
dfe: 33
adjrsquare: 0.9988
rmse: 0.0579
Plugging in the plausible scaling factor.
 Code: Select all
General model:
mast_fit(x) = 13 + 1 / (1 / 150.4 + 0.956 / (x * 0.5 / 2.2)) + b
Coefficients (with 95% confidence bounds):
b = 6.625e07 (0.02053, 0.02053)
mast_fit_GoF =
sse: 0.1142
rsquare: 0.9987
dfe: 33
adjrsquare: 0.9987
rmse: 0.0588
 mythor
 Posts: 24
 Joined: Sat Aug 25, 2012 4:21 pm
Return to Advanced Theorycraft and Calculations
Who is online
Users browsing this forum: No registered users and 1 guest