---

Q u o t e:


I do not believe SoC procs off of Judgment like SoB does. I shouldnt have muddied the waters with Judgment though. >.<

In good news however, 2h Spec boosts seal damage. :]

---

If you keep judging, you'll eventually see a JoC -> SoC.


Yes, it's O_o. Only happens with SoV, SoB, and SoC, as far as I can tell. (JoV causes the SoV stack to increment, giving it silly self-synergy)

---

Q u o t e:

If you keep judging, you'll eventually see a JoC -> SoC.


Yes, it's O_o. Only happens with SoV, SoB, and SoC, as far as I can tell. (JoV causes the SoV stack to increment, giving it silly self-synergy)

---

i <3 being able to keep up a full stack of SoV while healing a raid as holy. :D

I did another SoC haste test on the PTR, since my original test used Judgements and i'm not sure if Judgements proc'd seals then.

331 Haste rating (+20.99% haste), Torch of the Damned (3.8 AS), Glyph of SoC (8.4 PPM)

400 swings
219 SoC procs

(Recount screenie available on request)

219/400 = 54.8% effective proc chance

Haste	Scales	Doesn't

%chance 53.20%	43.97%

Swings	400	400

SD	9.98	9.93

+2 SD	232.8	195.7

Expect	212.8	175.9

-2 SD	192.8	156.0

Haste Scaling predicts 193~233 SoC Procs.
No Haste Scaling predicts 156~196 SoC Procs.


So Zamm, which model fits the data? Which model predicts the number of SoC procs?

i dont like how small your tests are nor do i like the lack of control... ill be posting some data with a handful of 1000hit parses soon, but not in this thread

---

Q u o t e:
i dont like how small your tests are nor do i like the lack of control... ill be posting some data with a handful of 1000hit parses soon, but not in this thread

---

I'm not trying to precisely determine SoC's proc chance, so the smaller test doesn't impact the results.

What's the point of a control? Is there a reason not to assume 7 PPM? A lot of previous work was done to understand SoC mechanics, so I didn't see the need to reinvent the wheel here.

because you're imposing a scenario based on a dichotomy with incorrectly gathered data

perhaps if you were more thorough another theory might arise as opposed to forcing the haste notion

---

Q u o t e:
because you're imposing a scenario based on a dichotomy with incorrectly gathered data

perhaps if you were more thorough another theory might arise as opposed to forcing the haste notion

---

What's incorrect about my data?


Also, what other possibilities are there to explore? Partial scailng with haste? Negative scaling with haste? Is it distinguishable from simple "haste scaling"?

---

Q u o t e:
I did another SoC haste test on the PTR, since my original test used Judgements and i'm not sure if Judgements proc'd seals then.

331 Haste rating (+20.99% haste), Torch of the Damned (3.8 AS), Glyph of SoC (8.4 PPM)

400 swings
219 SoC procs

(Recount screenie available on request)

219/400 = 54.8% effective proc chance

Haste	Scales	Doesn't

%chance 53.20%	43.97%

Swings	400	400

SD	9.98	9.93

+2 SD	232.8	195.7

Expect	212.8	175.9

-2 SD	192.8	156.0

Haste Scaling predicts 193~233 SoC Procs.
No Haste Scaling predicts 156~196 SoC Procs.


So Zamm, which model fits the data? Which model predicts the number of SoC procs?

---

Once you show your - haste control data then this looks promising to demonstrate that SoC scales with haste.

Although why did you bring in a Glyph of SoC, just to muddy things more? I can see that it increases the PPM, and so will decrease the size of n needed, but it is another variable.

I will run these tests myself once 3.0 goes live. Given that SoC has been played around with yet again I think it would be better to postpone tests until we have the finalized version. It saves wasting time on a build that gets changed, and would cut down on there being huge numbers of data sets all potentially showing different results from differing builds.

---

Q u o t e:


Once you show your - haste control data then this looks promising to demonstrate that SoC scales with haste.

Although why did you bring in a Glyph of SoC, just to muddy things more? I can see that it increases the PPM, and so will decrease the size of n needed, but it is another variable.

I will run these tests myself once 3.0 goes live. Given that SoC has been played around with yet again I think it would be better to postpone tests until we have the finalized version. It saves wasting time on a build that gets changed, and would cut down on there being huge numbers of data sets all potentially showing different results from differing builds.

---

What's the haste control data for? Do you question the assumption of a base 7 PPM?


I had a Glyph of SoC to test what it does. I found it was a multiplicative +20% to SOC's proc rate, though I didn't post the data from that test run. (7 PPM -> 8.4 PPM). Considering how hard it was to get the glyph in the first place, I didn't see the need to remove it. If you look at the results, it did not affect the testing. (And it does not affect n significantly, either)


After all your complaining about "clean data" and "correct methods", you have still contributed nothing to this discussion in data collection or analysis. Disappointing, though not surpising.

just discovered that judgements proc soc... have to through out about 5 hours of data and start over... stuff should be forthcoming as i find time to fit it in

---

Q u o t e:

What's the haste control data for? Do you question the assumption of a base 7 PPM?


I had a Glyph of SoC to test what it does. I found it was a multiplicative +20% to SOC's proc rate, though I didn't post the data from that test run. (7 PPM -> 8.4 PPM). Considering how hard it was to get the glyph in the first place, I didn't see the need to remove it. If you look at the results, it did not affect the testing. (And it does not affect n significantly, either)


After all your complaining about "clean data" and "correct methods", you have still contributed nothing to this discussion in data collection or analysis. Disappointing, though not surpising.

---

I have stated repeatedly that I will run these tests once 3.0 goes live. I see no point in running something in beta or the PTR at the moment where the builds are changing constantly.

And sorry for asking for controls, but I am used to scientific publications and if I was reviewing one that lacked them I would send back the manuscript and ask for them to be included.

---

Q u o t e:
I have stated repeatedly that I will run these tests once 3.0 goes live. I see no point in running something in beta or the PTR at the moment where the builds are changing constantly.

And sorry for asking for controls, but I am used to scientific publications and if I was reviewing one that lacked them I would send back the manuscript and ask for them to be included.

---

If you're not going to offer any data or useful analysis, the least you could do is take back the following:

"These data show that SoC is not working with haste still. Your data a few months ago, and the OPs data both had the underlying math correct. The problem was that you were drawing the conclusion you wanted, but one that could not be supported by the data as it was too messy. "


If you consider it a waste of work to test things on the Public Test Realms, you could have saved everyone here a lot of trouble by saying, "I don't like your method, but that looks interesting. I'll check it out on Live." Instead, you took raw data (that was also from the "constantly changing" PTR) and presented it to support the "conclusion you wanted". "The problem" is that the data in question, when analyzed, did not support your conclusion at all. You didn't do your homework, even while criticizing someone else's.

I'm not writing for a scientific publication. I'm taking well known statistical tools and applying them to gathered data, to show an interesting, unexpected result. You don't need to make something a full-fledged scientific experiment with carefully controlled variables in order to find out how something works.

your problem is that you didnt include judgments which could very well have inflated your overall proc number, along with the fact that by including special attacks you're fouling the data since there is no way to be sure that there is no overlap between autoattacks and specials, since we can all agree that soc has a cd of .5-1sec

---

Q u o t e:
your problem is that you didnt include judgments which could very well have inflated your overall proc number, along with the fact that by including special attacks you're fouling the data since there is no way to be sure that there is no overlap between autoattacks and specials, since we can all agree that soc has a cd of .5-1sec

---

The overlap between auto-attacks/specials would decrease the overall proc rate, which fails to explain the "normal proc rate" observed. Judgements proccing seals seems to be a recent change, but that's otherwise a valid criticism.


I gathered a second data set, in case you didn't notice:
http://forums.worldofwarcraft.com/thread.html?topicId=10043237942&sid=1&pageNo=9#162

400 doesnt cut it for me, sorry...
in my 1000 hit tests ive seen fluctuations from .5%+ .38 and back up to .45 ish all within the 2nd half of the test

I realize your intention but i still think your process is incorrect and you just may pushing for a biased result.

---

Q u o t e:
Source: Blatantly lifted from http://elitistjerks.com/899750-post3618.html. Thanks to Fiola for her testing.

Seems SoC scales with haste on the PTR.

Using 374 haste rating (23.72% haste + 3% from ret aura) with a 3.8 AS weapon (hasted to 2.98) on a servant mob in Blasted Lands. Overall test was about 10 minutes.

(I used a servant because dummies are now L80, so you miss 50% of the time; I would have had more haste if I had access to the epic haste gems as I originally planned)

205 white swings
160 SoC
87 CS
55 DS

Screenshot of recount:
http://img390.imageshack.us/my.php?image=sochastexd1.jpg

I got 160 SoC procs over 347 hits, for a 46.1% proc chance. At 7 PPM, we'd expect SoC to have 44.3% proc chance with a 3.8 AS weapon.

Using the SD analysis from the previous SoC haste discussions:

SD = Sqrt( % chance to proc * % chance to not proc)
Expected = swings * % chance to proc

In the following table, it shows the predicted range of SoC procs if it were to scale with haste or not. Using the 68-95-99.7 rule , 95% of results should be within 2 SDs. (http://en.wikipedia.org/wiki/68-95-99.7_rule)

Scen.     |   Scales   |  !Scale

%chance   |   44.33%   |   34.77%

SD        |     9.25   |    8.87

+2 SD     |   172.3    |  138.4

Expect    |   153.8    |  120.6

-2 SD     |   135.3    |  102.9

At 160 SoC procs, it is within the range of scaling, but not in the range of non-scaling. That suggests that SoC does scale with haste. (On PTR, anyways. I need to waste 150+ badges if I want to test this on live)

---

Are you really sure it increases with haste, or are you not realising that CS and DS (maybe even judgements) now proc seals, because you certainly used them in your attack cycle.

read the whole thread befure you post repeated criticism.
thats been covered,
wont be posting here anymore, focusing on my own testing which will be much cleaner

it seems like doing just auto attack should result in the cleanest test possible, yes? so why not just do that? no specials to get in the way.

It may be that the proc rates vary depending on the haste of each particular attack, so the unhasted specials would be skewing the data. For example, it would be nonsensical to have a rogue's slice and dice lower the proc rate of enchants etc on specials, but the proc rate is definitely lower on hasted melee attacks.

Might be something to look into and just do a test with solely melee.

I cant believe i just read this entire thread.

My conlcusion:

Zamm doesnt know what hes talking about