Theorycraft 101: Haste Breakpoints, update.

This is a minor update to my prior post on haste breakpoints, with a revision to the rounding formula that results in a slight change to a small set of breakpoints.

The previous post is here. You should familiarize yourself with the basic results if you haven't yet:
http://elitistjerks.com/blogs/1152-h...ints_rounding/

There I gave this description of how the rounding works:

• 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.

The first conclusion still holds, but the latter wound up being problematic. Warlocks found that if they geared their haste such that their Corruption tick time was exactly 2.400 seconds (corresponding to 7.5 ticks of the 18-second DoT), the game gives them 8 ticks instead of 7. See a comment by Erdluf about this in the prior post. We wound up talking about this a bit more, and his first guess was that the game uses "bankers' rounding"--when a number lies exactly on a half-integer, it is rounded toward whichever number is even.* We checked a couple more examples and they all fit with this. So I wouldn't say this is totally confirmed, but it seems likely so far.

Result

In the prior post I gave this formula for exact breakpoints with rounding accounted for:
,
where the half-brackets are a ceiling operator that rounds up to the nearest 0.001 seconds.

That formula should still be used when k is odd. When k is even, however, use this instead:

The only difference is that the ceiling has changed to a floor function, and the - after it became a +.

In the vast majority of cases, these will produce exactly the same result. The only time there's any difference at all is when

is an integral number of milliseconds (i.e. expressed in seconds, it has no more than 3 decimal places).

----

*Aside: rounding halves towards the even integer is not all that unusual. It's often considered good practice among e.g. scientists because rounding always-up or always-down introduces a slight overall upwards or downwards bias in the data. I'm assuming this is also where the label "bankers' rounding" comes from--accountants probably do this to make sure that when the deal with long lists of amounts, the total doesn't get biased up or down. It's not surprising to find this behavior in the game either, as this is the default rounding behavior in floating-point frameworks that are compliant with IEEE 754.