Haste as it is the most common second-secondary stat people turn to after mastery. A lot of great work has been done on this subject by many people one of which is by Binkenstein over at Totemspot and Hamlet. I have also discovered this spreadsheet which is an excellent resource of almost every class which I will be basing my calculations off of.
At level 90, 425 points of haste rating is equivalent to 1% haste. This is essentially a 1% faster cast speed. If you have 425 haste rating/1% haste, a spell which takes base 3 seconds to cast will now cost you 2.97 seconds to cast (1% of 3 seconds is 0.03 seconds, subtract this value from the total cast time). The debate between eternal flame and sacred shield is an animal within itself but for now, let’s assume we’re using eternal flame. The HoT component of this spell scales with haste. When you put the eternal flame on someone, the buff will last for 30 seconds regardless. Under no haste conditions, the HoT component of the buff will tick every 3 seconds for a total of 10 ticks. Increasing your haste decreases the time between the HoT ticks but does not decrease the duration of the buff. Therefore, you could potentially get more ticks of a HoT with more haste in the same duration or more healing with less casts.
You can imagine each HoT tick as a mini-cast because then you can apply the same logic of how haste affects spell casting to HoTs. In 30 seconds, EF will cast 10 times for a 3 second cast time each. With a certain amount of haste, the cast time of each EF tick could potentially decrease to say a 1.5 cast time and then in a 30 second time frame, EF will be able to cast 15 times/tick 15 times. I’ll refer to ticks for clarity rather than casts when I talk but I hope you can see that haste affects HoTs in a way exactly how it affects spell casts.
Perhaps you have heard of the term “breakpoint” when referring to haste. You can think of breakpoints as essentially values where special things happen. With no haste recall, in the 30 seconds of the EF buff, the HoT will tick 10 times. With some haste, you can push the time between ticks down. But only at specific values will you be able to get exactly a certain number of ticks. In other words, it is possible for example that EF ticks 10 times and be one-third of a way to the next tick. That extra 1/3 time to tick was not able to complete to a true tick and therefore the haste you had to reach the extra 1/3 tiem to tick goes to waste. We therefore define breakpoints as haste values where we will exactly be able to get complete ticks off so we can use any haste which will not help us reach complete ticks for other things like reforging to mastery.
Refer to the eternal flame information under Paladin on the spreadsheet I linked above (which I could not find a source anywhere for but would like to give credit where it’s due). The durations of everything are calculated in milliseconds (1000 ms in 1 second). The duration of the eternal flame buff is 30 seconds or 30,000 milliseconds and the base tick speed of every 3 seconds/3,000 milliseconds for a base 10 ticks. For 11 ticks, the tickspeed required is roughly 2,857 milliseconds or 2.857 seconds. Without any other considerations, you could identify the tickspeed by simply dividing the amount of ticks you want from 30 however WoW incorporates different rounding mechanics which makes the calculations more complicated.
Rounding is a very simple concept and you can view it in a sense as the summary of the most important parts of a number. A number like 9.2 using the traditionally sense of rounding goes to 9 where as any value 9.5 or above will round to 10. When calculating the tick, traditional rounding will cause any thing above 10.5 ticks round to 11 ticks. In other words, if the haste you have is enough for you to get at least half another cast of the tick in, then you will automatically be granted the extra tick. That is why in the formula for “Tickspeed required” you see an additional ” – 0.5 term”. (You can see why getting additional haste for example for 10.6 ticks is useless due to rounding and the reasoning behind wanting to identify breakpoints.)
Tickspeed required = Duration of EF Buff (30,000 ms) / Ticks – 0.5 = 30000 / (Ticks-0.5)
The final method of rounding used in the game is not the traditional sense as I described above but rather a different form of rounding called “Banker’s Rounding”. This is not supposed to be used as an indication of the unfairness of this type of rounding and rather as Wikipedia notes, the nomenclature’s relation to actual Bankers is rather obscure and unfounded. Banker’s rounding is more of a way to ensure that after certain mathematical operations, the result is closer to the truth. In fact the other name for Banker’s rounding is Gaussian rounding named after Karl Friedrich Gauss (an extremely important mathematician)(http://eetimes.com/design/programmable-logic/4014804/An-introduction-to-different-rounding-algorithms) (http://www.xbeat.net/vbspeed/i_BankersRounding.htm) In other words, it is good that Blizzard uses Banker’s rounding because after certain mathematical operations it is more accurate. This does complicate the haste calculation to some extent but it does not do so needlessly.
Banker’s rounding rounds every number which ends in a half to an even digit. 6.5 in the traditional sense of rounding would go to 7 where as using Banker’s rounding it would go to 6. Values such as 7.5 would follow traditional rules. Examine the formula below for the “Adjusted tickspeed required” which is the same as the one in the spread sheet above but changed slightly to work in Microsoft excel and to generalize terms. This adjusted tickspeed required applies Banker’s rounding to the Tickspeed required row above.
We will go through this formula exactly and see that each part has a very simple reasoning behind it.
In practice, Banker’s rounding only goes into effect when the traditional sense of rounding results in a left over half tick and only when the ticks are even. (ex. 10.5 ticks). The first requirement is modeled by the first part of the formula:
IF(MOD(30000, ROUND(Tickspeed required, 1)) / (Tickspeed required) = 0.5…
Variables and functions:
MOD(a, b) = excel function to identify the remainder of dividng a / b
- a = 30000
- b = ROUND(Tickspeed required, 1)
ROUND (a, b) = excel function to round the number a to the bth decimal point
- a = Tickspeed required
- b = 1, first decimal point
IF(a, b, c) = excel function which evaluates the truth of the statement in a, returning b if the statement is true and c if the statement is false
- a = If there is an extra 0.5 ticks exactly, if we are halfway through the cast of our next tick
- b = return value is a is true
- c = return value if a is false
The IF statement as mentioned evaluates whether we are halfway through the cast of our next tick. It’s easier to describe the FALSE statement first so lets tackle that.
If we are not (FALSE) then the formula returns:
FLOOR(Tickspeed required, 1) + 0.4999
- FLOOR(a,b) = excel formula to round down a to the bth decimal point
- a = Tickspeed required
- b = 1, first decimal point
I’m not sure whether this evaluation is actually what Blizzard does, or what is generally used for calculation but essentially, it leaves the Tickspeed required the same but generalizes it to nearly the maximum value before it is rounded to 0.5. Recall that this statement is only evaluated if we are not halfway through the cast of our next tick therefore this statement puts us right on the brink of falling in to exactly that. If that is confusing it’s not too important, the main picture is the Adjusted tickspeed is equivalent to the Tickspeed required as long as we are not exactly half way through a cast a.k.a. no Banker’s rounding is required. The 0.4999 is added on or in some cases 0.5 to act as a buffer.
Now lets tackle when we are exactly halfway through a cast of a new tick or when the statement above evaluates to TRUE. If we are (TRUE) then the formula calls a new IF statement:
IF(ISEVEN(30000 /Tickspeed required),
- FLOOR(Tickspeed required – 1, 1) + 0.4999,
- FLOOR(Tickspeed required, 1) + 0.4999)
Since this is an IF statement, it has a true and false evaluation of its own which I’ve separated by line breaks. This IF statement tests whether the number of ticks half ticks we get is even which recall is the second requirement to implement Banker’s rounding. The first term is what is returned if the first if expression testing whether the tick count was in between is true AND if the resulting number of ticks is even.
FLOOR(Tickspeed required – 1, 1) + 0.4999
This is Banker’s rounding in action and says that if our number of ticks is even, our required Tickspeed is actually lower than what is stated with normal rounding as Banker’s rounding will round a number such as 6.5 down rather than up. Thus, since the number of ticks will be rounded down at 6.5, you would already include the lower tick speed speed required.
On the other hand, if the statement is false, or the number of ticks is an odd number such as 11.6. Suppose our Tickspeed required is 2586.2. This false statement would turn this value in to 2586.6999. In essence, if the number of ticks is an odd number, we would not be required to have as much haste as expected. This is simply because Banker’s Rounding will always round odd numbers up and the Tickspeed values you have overshoot the required Tickspeed.
As many people mention, the situation where Banker’s Rounding actually comes into play is very rare and in most cases it is perfectly find to perform normal rounding. Let’s see when this actually is going to come in to effect. Consider that actually haste rating must be an integer. Even when trinkets have procced, the haste rating value still must be integer. I calculated all of the possible haste ratings from 0 to 20000. The resulting haste % can be calculated by dividing this value by 42500 (the conversion rate which will change the rating to a percentage) and adding 1. Then for holy paladins I multiplied this value by the raid buff of 5% and 10% holy insight buff to get a total haste percentage. Following this, I calculated the resulting number of ticks with this haste % from the equation given by Binkenstein (Hasted Ticks = Buff Duration/Base Tickspeed * Haste %, Buff Duration = 30,000 ms, Base Tickspeed = 3,000 ms). From this hasted ticks value I calculated the required Tickspeed. We can now identify situations which will fall under the case where Banker’s Rounding occurs by simply taking the first two IF statements from the above excel formula and plugging in the hasted tickspeed requirements to see when they both evaluate as true. What we eventually find out is that none of them are true. When I’m unclear of is exactly when the banker’s rounding occurs and where the tickspeed is calculated. Is the haste rating used to calculate the number of ticks or the tickspeed first? If this Banker’s Rounding value was discovered, where or how was it discovered? With integer haste ratings, you will never an exact 1-digit decimal value and your Banker’s rounding will never NOT equal traditional rounding of the tick.
Regardless of the results of this analysis, it’s interesting to note one thing. It’s very important which side the calculation begins on. If you assume a certain tickspeed required and then calculate the required haste, then you will get a different value than if you simply look at all of the haste values and calculate the resulting tick. To be clear, lets call defining a tickspeed to calculate required haste, initial ticks, and calling the number of ticks resulting from knowing the haste, resulting ticks.
My spread sheet listed for example, for the transition between 12 and 13 ticks to be at a Tickspeed of ~2500. However, their spreadsheet shows the cutoff from 12 to13 ticks to be at ~2400. This is where you must be careful. The equation to get a Tickspeed of 2500 was by subtracting 0.5 from the number of Ticks and dividing this value by 30000 due to the rounding of tick values. However, this equation can only be used on the resulting ticks as you can not subtract for example 0.5 from 12.5 because you will expect 12 to round to 12.5.
Similarly, you can not use the equation knowing initial ticks, which was simply 30000 divided by the number of ticks you want on the resulting ticks because this will not give you the minimum haste required (while it will of course give you one of many haste ratings possible to get your desired initial ticks). Therefore 3496 as it has been stated in some places I believe will not get you the required 13 ticks. This value is calculated by using a number near 12.5 as the initial tick value when it should be the resulting tick value. The true value should be 3506 at a minimum. This of course can be tested out and I may be proven wrong.