I'm in a hurry, so can't comment on the rest yet, but JFYI

The 1.8 Spd dagger test lasted 1:36:30 (hr:min:sec).
3355 player swings were registered in this time frame (by 2 different addons). 660 times I parried.
I did not save the combat log though.

One can expand this test for as long as your durabilty permits. One is practically invincible to these mobs as a def tank.
Fun fact: the durability decreases with hits connecting to your armor ... not with damage received. In one test my shield broke after 3 hrs or so.

EDIT: I see that I have another data point in my collection of tests (was rather bored at that time .
It was done using a grey 1.3 Spd dagger and wearing 3 passive haste items with a total of 111 haste rating.(total haste from these = 7%)
Thus the base speed was 1.21
The test lasted 1:00:30, registering 3046 player swings.
The observed player parry rate was 17.5% (313 times).
The observed haste was 1.5%
My predicted parry haste would have been 1/(0.76+0.825^0.61*0.24)=2.7%
Even a bigger error in this one.

As these errors grow larger the smaller the base speed gets I'm tempted to assume this is due to rounding errors. Have no other clue.

Well Ciderhelm, this was the interesting part of the experiment to me.

The main reason for getting and parsing the data was that I was sure that the theory as presented in wowwiki was wrong. It turned out that the original understanding of it was spot on, and I ate the proverbial crow. The only "new" piece of Parry mechanics that I think comes from this thread is the fact that it's always the mainhand that's hasted, unless that was also already in the original theory too

But yes, even though I was wrong about conventional wisdom being wrong, it doesn't seem like a wasted excercise since now we can it verified.

I can't see how you derived your formula for the theoretical chance, and defnitely not estimate its error, however the statistical error in the experiment is extremely small. You got 660 parries in something close enough to a poisson process (chance per timeframe -> 0 and time -> infinity but timeXchance/timeframe=non-infinite non-zero number), therefore the deviation in the number of parries you're expected to get if you repeat the experiment is 660^0.5=~25.7. We can look at that number as the "measurement error".
The error in parry chance meausred is then 25.7/3355=0.766%.
However turning the parry chance measurement error into a haste gained from parry measurement error, we need to assume that the formula you used to calculate it is correct:
haste=(0.76+(1-parry)^ratio*.24)*weapon_speed
Assuming the only measurement error (with delta(time)/time<<delta(parry)/parries, or in other words the error in number of parries is by far the most significant part of measurement error that the error in time or number of swings is neglicible in comparison)
deltahaste = |d(haste)/dparry * deltaparry| = 0.24*ratio*weapon_speed*(1-parry)^(0.24*ratio-1) = 0.24*1.8/2*0.803^(0.24*1.8/2-1)*deltaparry=0.25*0.00766=0.0019
So if the parry rate -> haste increase is correct or even close to correct the error in your measurements would be ~0.2% which puts your calculated results WAY out of the range of statistical error, meaning your approximation formula (which I still don't know how you derived) can't be correct if the formula I used is correct. Not to mention your theoretical numbers are always higher than reality, yet you have no explanation regarding what assumptions you were taking that were causing that.

In order to claim that the theory may still be correct and excuse the difference betweent the theory and reality to an "approximation error" when the approximation always give a significantly higher value than the practical (except maybe the 3rd experiment), you have to base it on what the approximation was and how it ended up with higher than real values.
For example when you use a linear "first approximation" and get too high values all the time you can say the "second order" addition will always be negative and that is what is causing the values to always be higher.

Botton line is that the data doesn't have any meaningful statistical errors to it (except for the last experiment for which you should do a much longer test to reduce the statistical error to much less than 0.2% to see if it behaves the same). The formulas used for calculating the theoretical value are WAY off.
Normally when calculating this sort of things you will be assuming things like rolls->infinity and chance per timeframe->0, however I don't see how such an assumption would ALWAYS tilt the results upwards. Nor do I know exactly what your assumptions were when you reached that formula, as no matter how I look at it I get formulas that aren't looking anything like yours.
Of course it could also be that the formula you were taking from previous posts is the incorrect one, or that you're combining the formulas wrong.

The stochastical lessons I took have been way in the past ... too long for me to remember so I take your calculations for it.
As for my formula to estimate the parry chance on a player swing:

Obviously the player can parry only when an incoming attack has happened in the players swing time frame.
The more incoming attacks happen in this time frame the more often the inherent parry% (of the player) comes into play. I took the ratio of player_attackspeed/mob_attackspeed as the (approximating) value for these (lets call it) "opportunities".
I saw the player swing as a sequence of <#ratio> mob attack swings which can be parried or not.
The chance of a NONparry for each of these mobswings is 1-parry_rate.
The chance of a NONparry for the sequel of mob swings (which happen in ONE player swing) is (1-parry_rate)^ratio.
As a NONparry is the counter event to a parry, a player parries on his swing with a chance of
1 - (1-parry_rate)^ratio

I hope this makes clear my motivation for this rough approximation of a parry on a player swing.
"rough" because the speed of mob and player swings is not uniform (while mob swings were not parried because of level difference, the player swings were) and not aligned.
Even more so this "ratio" thing does not consider the fact, that the higher the ratio the higher the benefit of a parry-haste on the player as ist is most likely to happen in the first portions of the player swing. I only assumed an average case of .76*attackspeed parry hasted player swing.
These would be just 3 things not considered in my "formula".
I would not consider these effect to be major in the larger picture but they can for all reasons and purposes be the reason why my formula over estimates player haste. The nonconsideration of player parry hastes would lead to an overestimation as the player hastes reduce the theoretical "ratio" number in a slight way.
Add to this that all the problems and effects of a server client architecture were not considered at all (I think it is telling that the error in my prediction grows significantly with faster player weapons), we have more than enough room for an unilateral error.


In your second to last post you wrote
i did not opt to go this route because it is so simplified to the extent of being false.
You just cannot calculate the total chance of a sequel of mini events by multiplying. (just as your chance for getting tails once in a series of n coin flips is NOT n*0.5)
I did consider my approximation to be reasonable within the bounds of this experiment.
And I hope it becomes clear now how I came to it.

EDIT: Ok, I realized that you had a precondition there (player swing < mob swing).
And on second thought you might be right there with your simplified formula of parry*ratio for parry chance, and my formula is wrong here (some academical examples quickly show that).
I recalculated the predicted player haste with the simple parry chance when player swing < mob swing.
The prediction would be:
1.21 Dagger speed: 2.6%
1.80 Dagger speed: 5.2%
While these are slightly closer to the results, the error is still too significant. This is either to nonconsidered effects (lag, aformentiones deficiencies,...) or to the assumed 0.76 weapon swing haste of a parried player swing (IMHO most probable in the case of player swing < mob swing).
In either case I was wrong. Apologies.

To add a final statement:
I do not think a formula for player haste prediction is either necessary or really helpfull.
The tests showed that the player haste effect depends rather strongly on the number of incoming attacks per outgoing swing.
While the effective player parry was somewhat comparable (ranged from 17.5% to 23%), the observed haste effect varied from 1.5% to almost 9%. The key factor was weapon speed.
To put it in a formula like I tried was obviously unnecessary nitpicking.
As such, a parry burst is best avoided by careful positioning (of hunter pets e.g.) or ceasing the attacks as a tank in hazard situations (fear, healer death, mob ability spikes, ...). But we all knew that before.

See edited post. Sorry for that, but I thought I would be quick enough to edit my original post.

Before anybody goes any further on this, I suggest instead comparing parry-hasted swings to observed weapon speed isntead of the tooltip weapon speed. I ran around questing in silithus on my 59/60 prot warrior, and observed swing timers of up to 1.833s on my 1.7s Sang'thraze the Deflector. Parry-hasted swing timers varied, but were all within range of the 40% haste cap - at least, down to .013s, from the beginning few samples I measured. I haven't bothered to figure out how to parse it, considering I didn't perform this under controlled conditions; I'm not sure how one would parse this anyway - unless there's a parry-haste parser somewhere on the internet or you have to program it yourself.

I did, however, observe the 'haste-charge' theory to be false. That is, if you parry an attack in the last 20% of your swing timer, you're out of luck. The next swing isn't hasted.

As a counter-example:

The swing timer between the first two hits is 1.706s. Acceptable as a normal swing; and there's a parry well within the last 20% of the swing timer. The subsequent swing timer is 1.567s. A little short, but with parries at the beginning of swings, I'd expect to see something like the following:
An extreme example, I suppose, as it shortens the swing timer .013s more than expected; indeed, parries with an identical timestamp to a swing don't always register. Perhaps that's to do with the apparent variability of the actual swing timers.

I might note that a more complete version of the former log looks like this:

That is, after the 1.567s swing, there's a 1.887s swing; after that, a 1.546s swing - no parries involved for the second short swing - and then the mob dies (not shown). So that's -.133s; +.187s; -.154s - it'd probably average out in the end; I suppose one could argue that as latency issues, but I have relatively stable latency: and assuredly less than 187ms; I hardly ever feel any lag at all - it mostly hovers around 50ms, I believe. It also depends how the timestamps are generated for the combat log - it doesn't seem to make sense for the timestamps to be generated client-side, describing when the action was displayed, though this could (relatively) easily be tested - but to me, the varied swing timer bit feels right; swings never really did feel consistently spaced on some weapons, and I suppose this is what this anecdote of a log shows.

I'd post the log - or the acceptable instances of parry-hasted swings therein - but I'm not exactly sure how I can. Either way, I was just trying to explain the outliers in the graphs above - but I suppose the 40% haste/20% swing timer limit works out to be more or less right in the end.

I've come into this thread pretty late, but that's some excellent data you've got kicking around, kudos. My ping is likewise jealous. Not to "derail" the haste conversation, but going back to the previous question about the "super hasted" line...

I sat here staring at the workbook for a good bit and staring at all the hits preceding each super-hasted hit and am also baffled. The scientist in me can't let that go, though - that second straight "double hasted" line is entirely too perfect to not be statistically significant. If you throw a trendline over just those points, the error is almost nonexistent. There's got to be a reason.

On the other hand, of all the parries in the data, this happened on barely over 3% of them, and at least three people have looked at all of those data points and not found any pattern. Could it just be a bug, where sometimes WoW chokes and "accidentally" calculates as if it's double hasted? More importantly, if it is a bug, and the effect is mirrored on mobs (I see no reason it wouldn't be), then this could definitely be a case of random tank insta-gibs from a bug.

Hey - that's nice info. Since the other two parry graphs didn't show that, I wonder if the explanation is as simple as a virus scanner or some other regularly-interval'd local computer thing that stopped the combatlog writing process.

Or, even more ironic, the combatlog gets written in chunks, I think, and it may be that process on its own that produced a quasi-lag to explain those.

Or maybe not, but I'd be surprised if it were a game mechanic, per se, since the other two charts didn't show similar data (as far as I can interpret the dots).

I decided to grab the Spades spreadsheet that Disquette posted to do some re-interpretations of the graphs. The x-axis label "time until next swing," is the same as "time left on swing if no parry," or "you parried, and this is the time left until the next swing if you hadn't parried," but that would have been a rather verbose for an axis label.



Anyways, to the point. Here is a re-interpretation of the exact same data in terms of absolute swing time (i.e. if no parries occured, it would be a flat line across the top at 3.6s). You can see that anything below 20% remaining time (0-0.72s) hits at base speed, that anything between 20-60% remaining time (0.72-2.16s) gets a variable reduction in swing time and that anything 60% and above remaining time recieves a flat 40% reduction in swing time (which in this case always sums to 2.16s which is 60% of 3.6s).

To make this plain as day I made another graph with Disquette/Spades' previous contributions.



This graph shows the data in terms of Base Attack Speed (BAS) increase. (i.e. 1.66 increased swing speed = 66% BAS increase = 40% reduction in swing timer)
Attack Speed = BAS/increase swing speed or
Attack Speed = BAS/(1+%BAS increase)

Take note of the "double hasted" parries with 186-215% increased BAS. I've also taken a look into the spreadsheet and nothing stands out to me either. There is not enough evidence of double parries or lag to explain these hasted swings. The only pattern I can discern from this is that they occur only in the 75-100% until next swing time frame interval. My best guess is that there's a mechanic for if you parry within the first 25% time frame of your swing time (2.16-3.6s) to have a chance to proc a "crit parry" that doubles your base attack speed. We'd need more samples and character stats to know (parry rate, crit rate, etc).

The wowwiki parry formula definition is accurate except for the 20-60% range which is approximated in the graph below.



This is the 20-60% time section isolated from the rest of the swing data, converted into a swing time percentage and cleaned up a bit as some lag data was throwing off the poly-trendline (yes, this is not the proper thing to do statistically, but it's needed when the data point is 5 miles out and affecting the small sample size).

For example, a parry that occurs with 1.5 seconds remaining until your next swing (1.5/3.6 = 41.6% time) gets a BAS increase of [2.52*(.416)^2-0.3586*(.416)-0.005] x 100% = 28.3% increased BAS.

Note that this is a very poor approximation as there are only 66 data points for this region which isn't statistically significant considering all the noise (lag) and the incredibly small sample size. Sadly I left my engineering statistics textbook at school so I can't tell you how big of a sample we'd need to hit 2σ, but hopefully somebody here is a stats/math major.

In Summary:
Swings occuring in 60-100% swing time - get a Base Attack Speed increase of 66.6% (Attack Speed = BAS/1.66 = 0.6*weapon speed).
Swings occuring in 0-20% swing time - swings at normal speed.

Swings occuring in 20-60% swing time - get an increase in Base Attack Speed of roughly X=[2.5*(%time until next swing)^2 - 0.36*(%time until next swing) - 0.005]
Thus, Attack Speed = BAS/(1+X)

OR a more simple equation is obtained by integrating, getting the area and dividing by the time frame to obtain the average gives 28.806% Increased BAS:
Attack Speed = BAS/1.288 = BAS*0.776

In our case, the average swing time in the 20-60% region was: 3.6/1.288 = 2.795 seconds

Overall: 40%/1.66+40%/1.288+20% = 75% BAS
1% Parry Rating is equivalent to 0.25% haste

=============================================================
To find actual haste you need parry rate, mob attackspeed and player attackspeed
Regarding Suicuique's Formula, it becomes apparent that it will not work when you create an extreme scenario.

If the mob_attackspeed is 4, and the player_attackspeed is 1 and we have 100% parry
The equation would be 1/(0.776) = 28.8% haste which can't happen because we can only parry haste one out of four attacks.

The equations obtained from the graphs assume that each attack table has one and only one mob attack. In the case that the mob attack speed facilitates two attacks before one of yours, then the probability becomes (1-parry)^2 rather than just (1-parry)^X. The exponent for this expression MUST be a whole integer if greater than or equal to 1 (There's no such thing as 2.5, swing count must be an integer)

The correct equation for equivalent haste due to parrty is as follows:

Let X = player_atkspd/mob_atkspd
Predicted Haste = (X)*{ (1/ [0.776 + (1-parry%)^(X***)*0.224] ) -1} x 100%

X***
If 0 < X < 1, X∈R (real number domain)
If X > 1, N = {1,2,3...}
So, for your 3 observed cases:

1) PH = (0.9)*{(1/[0.776 + (0.77)^(0.9)*0.224]) - 1} = 4.4%
2) PH = (1.3)*{(1/[0.776 + (0.778)^1*0.224]) -1} = 6.8%
3) PH = (1.85)*{(1/[0.776 + (0.795)^1*0.224]) -1} = 8.9%
4) PH = (0.605)*{(1/[0.776 + (0.825)^(0.605)*0.224]) -1} = 1.5%

Predicted = Observed ∴ formula is likely to be correct (although we should get more data sets)
I believe these are the values you are looking for