Elitist Jerks Theorycraft 101: Haste Breakpoints and Rounding

Rate this Entry

# Theorycraft 101: Haste Breakpoints and Rounding

Posted 07/18/11 at 10:01 PM by Hamlet
Updated 08/09/11 at 3:01 AM by Hamlet
Trying another one of these since I think the mana regen one turned out pretty well. This one is going to be slightly different. Many people have written descriptions of how these work, since it was a clear and interesting new topic. So I'm going to give a pretty terse summary of the basic computation, and then outline one further detail which is missed by most popular write-ups: the exact way the rounding works in-game. With that knowledge, you can compute breakpoints that are exact to a single point of rating.

# [top]Introduction

In Cataclysm, all DoT/HoT effects have their tick rate increased by haste. Since this causes the DoT duration to not be an integral number of ticks, the game rounds the duration to the closest whole number of ticks. Haste breakpoints are those amounts of haste at which you get a whole tick added on.

Breakpoints are important for gearing because the haste contribution to your DPS and healing jumps up at certain points. For some classes (Resto Druids are the best example), it is worth it to modify your gear setup quite significantly to obtain a whole extra tick on a spell that you use often.

# [top]Variables

Throughout this post:
• D is the default duration of the HoT or DoT in question.
• n is the default number of ticks.
• t is the default tick time (equal to D/n)
• k is the number of the tick we're trying to add (i.e. if we're computing the haste needed for the 5th tick of Rejuvenation, k=5).
• H is your combined haste from %-based haste buffs (so if you have both Moonkin Aura and Dark Intent, H would be 1.05*1.03=1.0815).
• s is your haste rating.
• R is the "haste constant", equal to 12,805.7.

# [top]Review of basic computation

To determine the number of ticks a DoT will have, the game does the following:
• Apply your total haste to the default tick rate to determine the final tick rate.
• Divide the default duration by the final tick rate to find the (fractional) number of ticks.
• Round that number up or down to the nearest integer to determine the final number of ticks (and adjust duration up or down to accommodate).

Mathematically:
$H(1+s/R)$

Therefore, buffed tick time of the DoT is:
$\frac{t}{H(1+s/R)}$

Number of ticks before rounding is:
$\frac{D}{\frac{t}{H(1+s/R)}}= nH(1+s/R)$

In order for the DoT to achieve k ticks, that number must be high enough to be rounded up to k. In other words, it must be at least (k - 1/2). Therefore the breakpoint occurs at:
$nH(1+s/R)= k - \frac{1}{2}$
Solving for s:

(Note that D and t have nicely dropped out--only the default number of ticks n is needed)

This is the derivation for the formula that I have in this post a while back:
http://elitistjerks.com/blogs/1152-h...e_breakpoints/

# [top]Rounding

For a while class, theorycrafters used the above equation or something identical to it to predict their breakpoints. Problem is, it didn't work out exactly in-game. You'd gain the extra tick somewhere close to the predicted amount (within 5 rating usually), but not exactly at it. It was clear that the game was rounding something at some step of the way.

This was hard to test since it was necessary to keep adjusting haste by very small amounts near various breakpoints (since different guesses at how the rounding worked only changed the results to the tune of a few points of rating). I was looking into it, as were people on other EJ class forums like Warlocks. Eventually a hypothesis came out which predicted all breakpoints exactly, which is the following:
• After haste is applied to the tick time, that tick time is rounded to the nearest millisecond (0.001 seconds) before the total number of ticks is computed.
• If the number of ticks before rounding is an exact half-integer, the game rounds down instead of up (EDIT: this has been revised slightly--read update here: http://elitistjerks.com/blogs/1152-h...points_update/ ).

So the resulting calculation is modified as follows.
Tick time before rounding was:
$\frac{t}{H(1+s/R)}$

Tick time after rounding to the nearest millisecond is:
$\left\lfloor\frac{t}{H(1+s/R)} + 0.0005\right\rfloor$.
(The half-brackets are the floor operator--I'm using them here to mean "round down to the nearest 0.001 seconds." I'm expressing the rounding by adding half a millisecond and then rounding down, because it simplifies a later computation).

The number of ticks before rounding is:
$\frac{D}{\left\lfloor\frac{t}{H(1+s/R)} + 0.0005\right\rfloor}$
Sadly, due to the rounding, the D/t doesn't nicely drop out anymore. Different duration DoTs can have different breakpoints even if they have the same number of ticks.

To find the final tick value, round that expression to the nearest integer, with the above proviso that exact half-integers are rounded down.

What we really want to do though is solve for s as we did before to find the breakpoint. Once again, the pre-rounding number of ticks must be greater than (k - 1/2).
$\frac{D}{\left\lfloor\frac{t}{H(1+s/R)} + 0.0005\right\rfloor} > k - \frac{1}{2}$

Juggling the algebra here is a bit more of a pain due to the ceiling operator, but it goes like so:
$\frac{D}{k - \frac{1}{2}} > \left\lfloor\frac{t}{H(1+s/R)} + 0.0005\right\rfloor$
What happens here is a bit tricky. Remember that the right side of the equation is an integral number of milliseconds, and the left side is the maximum tick time that will allow for the kth tick to occur. If you think about this for a minute, we can say that the number of milliseconds we need to "reach" is the ceiling of the expression on the left:
$\left\lceil\frac{D}{k - \frac{1}{2}}\right\rceil > \frac{t}{H(1+s/R)} + 0.0005$
From here, solving for s is simple algebra:
$(1+s/R) > \frac{t}{H\left(\left\lceil\frac{D}{k - \frac{1}{2}}\right\rceil - 0.0005\right)}$

$s > R\left(\frac{t}{H\left(\left\lceil\frac{D}{k - \frac{1}{2}}\right\rceil - 0.0005\right)}-1\right)$
The expression on the right is our haste breakpoint (again, the ceiling operator rounds the internal expression up to the nearest thousandth of a second, or 0.001 seconds).

This is an Excel expression that will give the needed amount of rating:
Code:
=CEILING((T/((CEILING(D/(K-0.5),0.001)-0.0005)*H)-1)*R,1)
Simply fill in the appropriate cells in your spreadsheet for D, T, K, H, and R.

(EDIT: Once more, find a slight update to this here: http://elitistjerks.com/blogs/1152-h...points_update/ , which will change the result slightly in a small number of cases)

# [top]Example

Once again, an example. As a Resto Druid, my only haste buff is the raid's Moonkin aura (H = 1.05), and I want to know how much haste rating is needed to reach the 13th tick of Lifebloom (a 10 second, 10 tick HoT by default). Variables:
• D = 10
• t = 1
• k = 13
• H = 1.05
• R = 12,805.7.

$\frac{D}{k - \frac{1}{2}}= \frac{10}{12.5} = 0.800$
0.800 second is an integral number of milliseconds (800 milliseconds), so the ceiling of it is still 0.800.

The final expression is then:
$R\left(\frac{t}{H\left(0.800 - 0.0005\right)}-1\right)$
12805.7*(1/ (1.05*(0.800 - 0.0005)) -1) = 2448.715.

And that gives us the exact amount needed to get that 13th tick: 2449 haste rating.

Note that if you used the earlier formula, without rounding, you would have gotten 2440 as your breakpoint, potentially causing you to miss the extra tick if you tried to gem to exactly 2440.
Posted in Math , TC101

 Your rounding does not seem 100% correct. When using this formula on a priests renew (5th tick), you get a haste rating of 517.57 (D=12; t=3; k=5; H=1.03*1.05). On the live servers you will get the 5th already at 516 haste. Posted 07/19/11 at 9:51 AM by forecore
 Working through it: 12/4.5= 2.6666666. Ceilinged up to the nearest thousandth, that's 2.667. Throwing that into the equation: 12805.7*(3/(1.05*1.03*(2.667 - 0.0005)) -1) = 515.9. This gives the 516 rating required that you say is reflected in-game. The formula is not most straightforward thing to apply, but the Excel expression I included should make it pretty easy to test various combinations quickly and without errors. Posted 07/19/11 at 11:46 AM by Hamlet
 Quote: Working through it: 12/4.5= 2.6666666. Ceilinged up to the nearest thousandth, that's 2.667. That is the part i screwed up. Thanks for clarification I always wondered how that rounding stuff works to really get the exact amount of haste rating needed. Posted 07/19/11 at 12:31 PM by forecore
 Current reforging programs/add-ons are disregarding stat priority in what appears to be a pre-cata mentality. Knowing INT>hit=haste>mastery>crit from previous posts, I am finding that after Patch 4.2 these add-ons are looking at haste breakpoints and actually suggesting the player reduce haste to increase critical strike if you are far enough away from the next breakpoint. For example, the 1932 or approximate breakpoint is ignored if the player has 1800 haste or less, and suggests reforging for crit (not mastery) and decreasing haste. After experimenting with this, I found that if you are close to the next set point it is always better to increase haste for the additional tick, yet am perplexed that these code writers are accentuating crit over mastery. What I have found is that by reforging to crit over mastery, I get bigger and more consisitent crits, and I mean big booms (100k or more with trinket and enchant procs) with less haste. Therefore, my question is simple, does crit now have more impact than mastery. And if so, how close to the next haste breakpoint should one be before they push to the next 'tick' over the big booms? Posted 07/26/11 at 10:03 AM by Parapebbles
 Afflocs report 8th corruption tick at 1993 (with H=1.05*1.03). Your formula gives 1999. They round up (18/2.4 = 7.5). Recently for simulationcraft, someone changed to your formula, and that got reverted (comments mentioned warlocks and spriests). Your formula is now patched into druid-specific code, but not in the more general all-class code. EJ's afflock post lists 1993. I haven't seen any sources with raw testing, but my impression is that Warlock DoT theorycraft tends to be pretty good. Posted 08/02/11 at 6:53 PM by Erdluf
 I mentioned this on Twitter and Binkenstein is starting to look into it here: http://elitistjerks.com/blogs/9184-b...n_vs_moonfire/ Posted 08/03/11 at 8:56 PM by Hamlet
 It seems the images here are broken Posted 08/29/12 at 11:11 PM by Warstorms