Dontmindme

Okay, might as well see if the discussion can get off the ground.
Let's make a few ground rules for the forum...
The purpose of this forum is to discussion rogue mechanics in-depth with an eye on how one might model such.

Examples of discussions that probably fit here:
1) Skill modeling (such as Deadly Poison) and how to accurately determine uptimes and/or proc rates at various intervals.
2) Proc mechanics. We can probably include discussions and determinations of these here. Of course some topics might branch off to their own topics. Executioner vs. Mongoose clearly deserves a topic of its own for example.

Examples of discussions that probably don't:
1) Discussion of which item is better. Here's the answer consult the spreadsheets...
2) Which build is better? Consult the spreadsheets...

In general I see this as a focused discussion topic for micro issues. Essentially discussions that one can arrive at a definable answer (well at least maybe) for a single problem. I don't really want to discuss the comparative benefits of this build vs. that build. A few spreadsheets have been built to try to do that. 2 are currently public, use them, love them.

 

Dontmindme

Okay, here is a previous portion of a post discussing possible Deadly Poison modeling...

So, I was trying to determine if this is true...
So I started by trying to break down what happens at any stack starting with a potential proc at T=0
This can be broken down into:
1) Within 12 seconds one gets a successful poison application
2) In 12 seconds one does not + a certain period of time to wait for the next potential proc
Now wait time for the next proc will run from 0 to one's integral attack interval and can be averaged as 1/2 the attack interval.

Now the problem, and why 1 stack probability is different from 0 stack probability is this 1/2 attack interval.
Using this first example, the whole time one is at 0 stacks as one is at 0 stacks until you get a proc and you are at 0 stacks when you do not get one within the 12 second interval and you are at 0 stacks during the 1/2 attack interval.

At 1 stack, you are still at one stack until you proc to the next stack; you are at 1 stack through the whole 12 seconds when you do not proc, but you are at 0 stacks during the 1/2 attack interval while you are waiting for the cycle to hit zero

Now if the attack interval became 0 the above equation would work, but it's not.
So the average % time spent at 0 stacks is greater than the average % time spent at 1 stack because part of the time as 1 stack has just be procced, ends up spent at 0 stacks.

The good thing is that the average time spent at 2 stacks does equal the average time at 1 stacks. Same as 3 stacks and 4 stacks. So, the relationship between time spent at 1 stack through 4 stacks is accurate.

This formula might still be savable if I can figure out a formulaic relationship between 0 stacks and 1 stack or some other way to accurately determine average time spent at exactly 1 stack.

So that's where this theory is currently at. If you change the D0 to D1 and figure out what D1 is it might be salvageable.

 

Pstar

What you seem to be theorizing here is: if I use Envenom as a finisher, how fast will the stack rebuild?

The D0D1 stuff is not incorrect, but it is a bit mathematically naive. The way the OP formulates it shows a classic example of a convergent geometric series, but then you don't use the geometric mean.

There's also some standard probability notation and binomial distribution shortcuts that would help.

Let P = the chance of success, and Q = the chance of failure.

If we reformulate the above...

D0 = PQ
D1 = P^2*Q
D2 = P^3*Q
D3 = P^4*Q
D4 = P^5*Q
D5 = P^6*Q

And add them up Sum(D) = PQ+P^2Q+P^3Q+P^4Q+P^5Q+P^6Q
Recognize that P is a positive number less than 1 (say, 20 to 30% depending on talents), and this series converges. It's not infinite, of course, because you can't have more than 5 stacks. However, we can probably fudge it slightly since P^7 and up terms will be very very small, and because otherwise there's no way to solve this without some fancy math software that I don't have (or know how to use).

So we can approximate SUM(D) as (1/(1-P)) * Q, which, of course, equals 1.... why are we doing it this way? Lemme dig up an old spreadsheet, I had a decent way of modelling it....

 

Pstar

NB: I assume we're talking about a mutilate build here with some slow daggers. I also assume we don't really care about the initial build-up of the DP stack, because we're trying to analyze envenom as a finisher. Finally, assume S&D and whatever appropriate haste.

1) First #: Average # of poison applications per second

[top] # hits per second * chance to poison
# hits per second

specials per second + white hits per second
specials per second are easy, for mutilate you get 2 hits every 6 seconds, thus 1/3
white hits per second are trickier, say you're using 2 1.8 daggers, with S&D up, and a 10% missrate (don't forget dodges)

[top] 1 / (weapon speed / haste mod / hit rate)

1 / (1.8 / 1.3 / 90%) * 2 (two weapons)
# hits per second is about 1.62, using these #s
chance to poison is 30%, so .49 poison apps per second

2) Second #: Time to envenom
What's your cycle here? Are we using rupture as a priority finisher? Figure it out. I came up with the # of about 21 seconds (but this was a long time ago).

3) Average stacks of DP7 = poison apps per second * time to envenom (in seconds)... I came up with about 3.2. For some reason I thought I should add 1 to the average stacks, I'm not sure why...

Anyways, that's one geek's perspective on the problem you seem to be working with. Cheers

 

Left

I can't contribute in any logical way to the mathematics of the model, unfortunately, since my background in statistics is well below the level you all are operating at here.

However, what I can do is try to create a simple numerical simulator to test any model we come up with. I've already got a spreadsheet which will do this for a PPM effect, and it closely agrees with what DMM and Aldriana came up with as a PPM uptime estimate equation. I think I can extend this to deadly poison modeling without much effort.

I think a code-based simulator would be more effective than a spreadsheet, however, since a spreadsheet has the disadvantage of "smaller" sample sizes. (By small here I mean that I'm running 10k attacks at a shot, then iterating multiple items to see what the average is. A code-based simulator could easily do 100k or even a million attacks and then average the results.) If there's interest in building a simulator like this to test the model, let me know and I'll put some work into expanding what I already have for PPM.

 

skorpeo

Another use of this would be to come up with a solid model on to shiv or not to shiv Deadly Poison as a combat build if the 5 stack is in danger of dropping.

 

Ozzmar

This is a good start, but there's one thing I think warrants some consideration: Relentless Strikes and the common sense of a good Mutilate player.

Mutilate is all about timing your finishers, and a good rogue will know to Envenom with nearly full energy so that a Relentless Strikes proc and a natural energy tick will allow him to Mutilate twice almost immediately.

This does a great job of showing the average poison applications over time, but it doesn't really model reality according to the way I understand Mutilate should be played.

Is there a way we can analyze those few seconds after a finisher? I think those are the most critical as the biggest concern with Envenom is losing the DP stack, and getting it back up as quikcly as possible is priority #1.

 

Left

I used to do this when I played mutilate: let my energy tick up prior to a finisher so that I could get the most of out Find Weakness. However, I don't recommend this strategy when using envenom. The reason is that since Envenom will wipe your DP stack, you want to wait a second or two for white hits to restart poison on the mob before hitting your next mutilate. Otherwise, your Mutilate will lose it's +50% damage bonus.

Sure, mutilating will put the stacks up there more quickly, but in my opinion the DPS loss from an un-poisoned mutilate is more than the loss you are getting from not having DP stack up quickly.

However, discussing Mutilate timing isn't really the point of this thread. What we're looking at, first and foremost, is an accurate model for DP on offhand white hits only; we can move on to more complicated crap from there.

 

• Aldriana

I've actually already written a simple modeling program for PPM effects, that I used to assess the models we found in the Roguecraft 101 thread; it takes about 10 seconds on my computer at work to simulate 10 million hits:

It should be reasonably easy to adapt to the simplified model of poison where it's just as 12 second buff; updating it to quantize poison to 3 second ticks would be a little harder but presumably also doable.

 

Ozzmar

Well, typically you're not the only rogue in a raid, nor are you the only character applying poisons to a boss. I see this as a non-issue, but you're right - I'll shut up and let the big boys talk.

 

Left

Uh, that is a good point...

I guess I was coming from the perspective of using Mutilate in 10-mans (the only place I've ever used it), in which case I was the only one poisoning the boss.

Re Aldriana: Yeah, that code version looks a lot nicer. I'll see what I can do with it; probably won't be today.

 

• Aldriana

Well, as long as we have a thread for it: time to put forward my previously alluded-to model of Deadly Poison uptime, which is impossible to compute symbolically and not the most practical thing numerically, but as it *does* work (as far as I can tell, anyway) it's probably worth discussing a bit. The fundamental approach is as follows:

Figuring out the amount of time between when one stack of DP ticks off and the next one starts is easy; hence, what we need to calculate is the average duration (and stack height) of an uptime period.

The way to do that - or at least, the brute-force way of doing that - is to define your initial state as a vector, and then write out the transition table. Now, we have two different pieces of state that we need to keep track of: the number of stacks currently applied (1-5) and the number of ticks remaining (1-4), plus an additional state of "no poison up". However, we don't quite need all those states; outside the initial state, we can never have more than 3 ticks remaining. So we really have the following 17 states:
(0,0)
(1,1)
(1,2)
(1,3)
(1,4)
(2,1)
(2,2)
(2,3)
(3,1)
(3,2)
(3,3)
(4,1)
(4,2)
(4,3)
(5,1)
(5,2)
(5,3)


So our state is defined as a 17-entry vector, with an initial state of "1 stack of poison up, 4 ticks remaining" (given that we have assumed that poison was just applied for the first time).

Now, how do we define the transitions? Well, pretty simple, actually. Let n be the number of attacks that occur in an average 3 second window, p be the probability that a given attack procs poison (hit rate * proc rate * proc resist rate), and q = 1-p. Then we have the following cases:

If no procs occur, the number of procs remaining goes down by 1; if there was only one proc remaining, we enter the "no poison" state. The probability of this happening is q^n.

If one proc occurs, "stacks" increases by one (to a maximum of 5), and "ticks remaining" resets to 3. The probability of this happening is npq^{n-1}

If two procs occur, stacks increases by two (to a maximum of 5), and "ticks remaining" resets to 3. The probability of this happening is .5*n(n-1)p^2q^{n-2}

And so on. So, for each state, theres at most half a dozen other places it can go; for instance, our initial state (1,4) can go to (1,3), (2,3), (3,3), (4,3) and, depending on attack rate, possibly (5,3), but it can never go to, for instance, (3,1) or (0,0). Similarly, (2,1) can go to (0,0), (3,3), (4,3), or (5,3) and nowhere else.

In reality, you could make these transitions slightly more precise by looking at the probability distribution of number of attacks and carrying those probabilities through this step, but I suspect that's overkill; this approach should work pretty well.

Anyway: now we have our transition matrix T. The next step is to diagonalize T (which is equivalent to computing the eigenvalues/vectors) and write it as PDP^{-1}, such that T^n = PD^nP^{-1}. This allows us to write a closed-form expression for the probability that the system is in any given state after n ticks as a linear combination of the eigenvalues of T, taken to the nth power (i.e., a sum of the form w_1 * e_1^n + w_2 * e_2^n * ... * w_17 * e_17^n

At that point, once can compute the probability that the stack wears off after exact N ticks for any N, and from there compute the expected duration. Also, since you have full state information for every tick from 1 to N-1, you can compute the average number of stacks as well. And since average downtime is easily (1/pt), that's enough information to get you across the finish line.

 

Pstar

Well, I applaud your use of matrix decomposition, but I'm not sure that it gets us closer to the answer. Incidentally, my training is in economics so my perspective is a bit more applied than yours. I would hazard to guess that your training was in electrical engineering or physics.

I'm unsure to what degree eigendecomposition of a 17 by 17 matrix is computationally tractable. (We only used Cholesky decomp in econ/stats). Mightn't all the zeroes in the transition matrix you propose make it un-decomposable/un-invertable?

Ultimately, any number for "average" damage we come up with is going to have a variance anyways. Good luck computing the second order behavior of your symbolic solution =). Or partial derivatives with respect to parameters (weapon speed, hit rate, haste, talents, etc). And then collecting enough data to validate or invalidate the model....

Well, on second thought, if you have matlab and are skilled with it, you could probably do it (except probably the data part, but that's not that important unless you plan on publishing this in a peer-reviewed publication a number that jives with a few WWS parses would probably be sufficient). You'd just need numbers for N and P, which is the easy part. What's stopping you?

I know what's stopping me -- I'm not good enough at math and am unfamiliar with the technique you describe.

So, being an economist and not a physicist, I prefer to make simplifying assumptions, namely:

1) The poison doesn't fall off until you wipe it off with an envenom -- reasonable if you're DW DP w/ mutilate
2) The base-case scenario you're simply leaving it to tick with 5 stacks the entire fight.
3) You can estimate an average CP usage cycle despite relentless strikes and seal fate

So the question as I see it would simply be, how often do you envenom, and how long does it take to build the stack back up?

 

• Aldriana

Pure math, actually, although I have studied a reasonable amount of physics, as well. But, fundamentally, yes: this is a totally abstract, symbolic solution. I make no claims that it's actually *useful* - just that it's a solution.

Numerically computing eigenvalues tends not to be *too* bad. I mean, it's certainly not an *easy* problem, but I think eigenvalues of a 17x17 matrix is fundamentally tractable. You're right that all the zeros may - and in fact, probably does - make the matrix uninvertable; however, my recollection is that any square matrix is subject to this decomposition in the general case (though admittedly it's been a few years since I studied Linear Algebra). And for purposes of this decomposition, having it be univertable actually makes life *easier* - the more 0 eigenvalues we have, the simpler the computations.

I don't see that variance is actually needed, but yes, I wholly agree that it's a clusterf*** of a solution. Computing it once is bad enough; having to compute it 300 times (which is roughly the number that would be required to include the model in the Rogue Gear sheet) would be much much worse. Again: not claiming that this is a good or useful solution, just that it's a solution.

Fundamentally? Because it's not a very useful solution, so I'm spending my time trying to come up with a reduction that's more tractable rather than pounding through the implementation of this.


Well, if you're DW Deadly Poison, this might be valid; however, I'd say the more common case for raiding rogues is that you have WF MH/DP OH, and in the case where you're only applying poison with OH, it actually drops a surprisingly large amount; for attack/proc/etc. typical for rogues, simulations of the simplified model have shown that one typically only averages about 4 stacks up at any given time, and the intuition is that for the real problem the answer will be even smaller. So while there's sort of the related problem of Envenom replenishment, the original problem being addressed here was "what is the average-case DPS for OH poison", which proves to be surprisingly complex, and the answer is not 5 stacks.

 

Left

Here's a quick and dirty Java simulation of deadly poison stacks. I did it on lunch break. It has some flaws - namely that it's not accounting for ticks but rather is treating poisons like a stacking debuff with uniform damage distribution. It also uses the attack interval as the basic unit of time. However, it should still give enough of a simulation to run a sanity check on any theoretical solution posed in the thread.

EDIT #2: I now believe that this program, while useful for a ballpark, is not quite accurate enough (even in the continuous case) to use as a benchmark for evaluating DP models. I found an issue with it that is causing it to overestimate DP uptime. See my post here for more info.

Aldriana's coding in Python, so it's a lot prettier than my crap up there. I'll probably be using Python after this, once I figure out how to work with it. Java is way too much of a pain.

EDIT: One thing I did notice was that for the defaults I entered, Improved Poisons is about dead even with Master Poisoner in terms on increased average stacks. However, both exhibit diminishing returns per point, so 1 point in MP plus 1 point in Imp Poisons increased poison damage more than both points in either of the talents. Interesting...

 

• Aldriana

For comparison: a simple (and not generally as good) DP modeling program I wrote a few weeks back:

However, this program is fundamentally inferior to the one I posted above, so I'd work of that rather than this.

 

Dontmindme

Let's start with the fact we are talking the general case, but it certainly has applications to Envenom modeling. The goal here is to accurately characterize uptime at any given stack size in a normal model where attacks are perfectly spaced over time.

Unfortunately, what you describe is the basis for the model I used. The reason I went to the D0/D1 formulation is because with the formula developed for ppm, we actually can accurately determine the % time spent at 0 stacks of deadly poison the same way. Based on the theory that this is a convergent system, I carried the rest of the calculations out. If you note in the original example, I actually solve for infinity by taking 1 - the probabilities for 0 stack to 4 stacks. I'm trying not to discard binomial terms just because they may be very very small, because some other numbers I'm using might be very very small as well. My formula was correct and would have worked in situations where the frequency of attacks was 0 (or essentially covered the range of all real numbers). It fails because of the integral nature of the sample set which causes the end time of each probability to be irregular between the 0 stack and the 1 stack. That probabilistic model works fine between 1 stack and infinity stacks because at each of these levels we have the same chance and duration of a small 0 stack tacked onto the end, with each probability of advancement being equal. The problem is that stack 0 gets the normal distribution of probabilities plus the sum total of these small 0 stacks of time at the end of each different numbered stack when it drops.

In short, the time spent at 0 stacks is non-conformist in length to the other seemingly similar stacks and is why that theory fails. You describe the same model I used, yet this model fails because it is incorrect with the ticking clock of attacks.

I should add the reason for the terms described as I did was to allow for a simple sum of products calculation to arrive at an average DPS. Using Bayes theorem one can add together terms based on the probabilities of each occurrence, or in short and simple terms one can get average DPS from Deadly Poison as:
(% time at 1 stack) * (damage per second of 1 stack) +
(% time at 2 stack) * (damage per second of 2 stack) +
(% time at 3 stack) * (damage per second of 3 stack) +
(% time at 4 stack) * (damage per second of 4 stack) +
(% time at 5 stack) * (damage per second of 5 stack) = average DPS of Deadly Poison

or in simple excel notion SUMPRODUCT(column1,column2)

So what you are describing as mathematically naive is actually much more spreadsheet efficient.

 

Pstar

@Aldriana:
I was tempted to guess pure math as well, but your solution almost seems too practical to have come from a mathematician =)

I kind of think variance is useful because it gives information about how much 'control' you have over your own performance. If we assume some risk aversion, a more volatile but slightly higher average dps could be worth less than a lower but more stable dps. This is why I'm still wearing a shapeshifter's signet -- upping my expertise to 5.75% means that my CP generation cycle is more stable (since the volatility is PQ=.75%*99.25%), and I really hate seeing the word dodge in yellow letters. A little more on variance below

@Dontmindme
The problem with your model is that (i'm pretty sure) excel won't let you calculate the % time at 1/2/3/4/5 stacks iteratively in the manner that you model it. You can have circular references and calculate iterations, but when you have 5 variables that you're changing at once and minimal validation criteria, Excel isn't going to help you. If you have some external source of the % time at 1-5 stacks, then a sumproduct would work swimmingly, but I thought that was the problem that we were working on. You have to reduce the # of variables. The 3 second ticks shouldn't really be a problem, we can just assume continuous time and the stepwise deviations should more or less average out.

Generally:

Here's a Morogrim parse -- my favorite T5 level fight, and I did pretty well on this one for being in a guild that just downed kael and has no BT/MH gear on anyone. WWS Loading...
Doh. I still had wounding poison on from FLK. But anyways, it ticked 98 times for an average of 84 and had 16 resists. (98+16)*3=342 seconds, and the fight was 346 seconds, so this checks out. I'm having a bit of a hard time calculating the theoretical WP damage... should be 65*1.16, i guess it's also affected by misery *1.05 and we have an enhance shaman so stormstrike too but probably not 100% of the time... hard to seperate out what stormstrike uptime would be and what average WP stack would be...

But, as a general solution, I would feel satisfied looking at a few parses and coming up with a haircut % for offhand-only poison.

What kind of dispositive questions are we trying to answer? If it's just "what's the DPS you get from offhand poisons in a cookie-cutter combat build with WF mainhand", then I'd just come up with a haircut%. DP OH is only like 5-10% of your DPS anyways, and it's not like you're going to change your behavior based on something we come up with here, unless i'm missing something.

One poster suggested "would it be worth it to shiv to keep DP from falling off" - this is a dispositive question (we'll change what we do based on the answer) but we hardly need calculus to answer it. i think the answer is almost unquestionably yes, but don't have the time to model it right now.

If we're saying, can envenom be a viable or superior finisher with mutilate builds, and how can we use math to inform the answer to this question, then I think we're asking something useful/dispositive. I think the answer is almost certainly no if you only have DP offhand, but I haven't tested it (I don't raid mutilate), but quite possibly if you have 2xDP.

I think my point about variance was also that, if the only question is "we all raid combat swords/fist+sword with DP offhand and we never envenom, how do we get the spreadsheet to most accurately predict my final DPS", then an elegant symbolic solution won't be much help anyways because of random chance. We should just say "well theoretically it should be X (x=5stack damage) but as a practical matter it's usually 90 to 95% of X, so haircut the theoretical estimate by 7.5%".

 

• Aldriana

Well, I like to pretend that my education was actually good for something every once in a while, so these things happen .

Variance has it's place, and modeling some things (*cough* SealFate) does require some serious thought about that. But given that Deadly Poison is such a small portion of your damage anyway (and not really under your control) I suspect no one is going to argue with a straight mean.
But, as a general solution, I would feel satisfied looking at a few parses and coming up with a haircut % for offhand-only poison.

Probably not. We're just obsessive perfectionists, is all.

Standing answer on this seems to actually be no, as the damage benefits are minimal at best and the micro requirements are large. But this would be answered decisively by solving the larger problem we're working on.

I'm not saying your intuition is wrong, but it seems to me that it is just intuition, and in a thread entitled "Advanced Rogue Mechanics Discussion" I think we want a little more in the way of hard numbers and a little less guesswork. I mean, fundamentally you're probably right that approximating OH DP as 85% uptime and assuming that Envenom isn't worth it without double poisons will give you more or less the right answers. But, there are those among us that want the answer in more detail, to actually come up with the numbers that prove it. And when you think about it, answering the general problem about average poison uptime will probably answer the related questions of Envenom and Shiv as well - hence that is the problem that I'm most interested in solving.

 

Pstar

re: Shiv, true enough, and it's not actually a situation i've ever really noticed and thought to do anything about. I'm too busy yelling at our moonkin to put imp FF back up.

Nice Java stuff above.

I think your modelling of the resist mechanics isn't quite right, though. According to my WWS it looks like the ticks are what get resisted, and not the application of the poison itself, although perhaps both can be? I'm definitely not much of a programmer, but I feel like a simulation similar to the above would be a good way to brute-force an estimation of the 'harder' questions we talked about above, and would actually be ideal for modelling mutilate since the different combo cycles you get from seal fate procs (which of course varies with your crit rate).

Anyways I'll keep reading =) good work

 

Dontmindme

I certainly understand the value of % uptimes as an estimate, but people using the spreadsheets (especially those using the DPS sheet to explore unusual builds) want to see more than that.

Let's say for example I hard code an uptime for DP. Someone decides that equipping a 2.6 speed offhand Fist weapon like Fury is somehow a good idea and looks at the DP number and sees they are still the same, essentially vindicating his decision. Now, the current DPS spreadsheet model for Deadly Poison doesn't seem that bad. It takes into account a number of factors and does factor in weapon speed. It just has a number of corners cut and some of the relationships can be proven to be not so accurate. These corners cut aren't so bad when one is just talking about offhanding a 1.5 speed weapon. I'm not as convinced of the results if one were to use Deadly Poison on both hands or in the main hand when one doesn't have a Shaman using WF in the party.

So, the short of it, as an Advanced Discussion, we are trying to determine more mathematically accurate models than have been currently implemented.

Now, much of theorycrafting is proving that something is inferior, but for some, they actually wish to know more exactly how inferior at different build levels. Furthermore, we have no idea what is going to change and by how much come expansion time. It's possible that Shiving to keep up DP stacks might be valuable is Poison damage were increased significantly relative to weapon damage. Having more accurate models in place, models that work off existing statistics will mean that one wouldn't necessarily have to reestimate % uptimes for all these items. We might be able to just use the new improved formulas and know a few days after the expansion is released what Deadly Poison damage might look like at level 80.

This is the point of this advanced forum. Ballpark estimates of % uptimes is probably more in line with a Roguecraft 101 discussion.

 

• Aldriana

Okay, I think I've found an approach that's a little more tractable - in fact, it's theoretically possible to do symbolically (although doing it numerically is probably the better option, as solving general cubics is... icky).

Fundamental idea relative to the approach in post 12 is that we separate the questions of "uptime" and "stacks" and consider them separately. This does degrade the model somewhat, as there presumably is *some* interdependency between uptime and average stack size (given that, for instance, any time after the first minute is necessarily spent at 5 stacks) but it is my hope that this is not a large influencer on the evaluation. And, frankly, even if it is, that might be workable... I have some ideas that might allow bookkeeping on that.

So, instead of the above 17x17 transition table, we throw out all notion of "number of stacks" and just look at "number of ticks remaining", which has allowed values 0, 1, 2, 3, and 4. So we're already talking about a 5x5 matrix instead of a 17x17 matrix, which is a step in the right direction.

Now, the next thing to note is that 4 stacks is only allowable as the initial condition, and always maps to 3. So we can actually just look at the 4x4 matrix corresponding to the values 0, 1, 2, and 3, solve for the average duration, and then add one extra tick to the answer to account for the initial 4->3 tick.

Now, what are the transitions here? Well, 0 can only map to 0, and for the other three values, k can make to k-1 or 3 (i.e., 1 goes to 0 or 3, 2 goes to 1 or 3, and 3 goes to 2 or 3). So now our transition matrix is a 4x4 matrix with only 7 nonzero values, which makes life look a heck of a lot nicer right off the bat. We can now start doing the same trick as above by diagonalizing the matrix to compute the expected time to drop in terms of the eigenvalues of the matrix.

Now, diagonalizing a 4x4 matrix is already a heck of a lot easier, but we can go one better. Since 0 stacks can *only* map to 0 stacks, we know that [1 0 0 0] is an eigenvector, with eigenvalue 1. Hence, we can factor that out and now only need to solve for 3 eigenvalues and 3 eigenvectors, which "only" requires solving a cubic to do symbolically, and can be done quite rapidly via numerical methods.

Regardless: at this point you can now get the full probability distribution of expected duration as as weighted some of powers of eigenvalues, which allows you to compute mean duration, variance, and basically anything else you might want to know; from this we can compute "average time that you have at least one stack up" and "average time than you have no stacks up".

Now, at this point, there's still the question of average stacks during uptime period. Well, as a simple model, approximating that the first 1/pn time is at one stack, the next 1/pn time is at 2 stacks, and so on to convert duration -> damage probably works pretty well; however, if you want a more detailed determination of what's going on to handle the dependencies better, you can do so by adding 2 more rows to our 4x4 matrix, one for "current number of stacks" and one for "total stacks applied so far"... which, alas, also include putting in the initial state (4 ticks remaining, 1 stack). But then you can use the "current stacks" to update the "total stacks", and the "total stacks" can then be read off during duration computation to figure out mean/variance/whatever for poison stacks. Now we're dealing with a rather more complex transitions in the cells of our transition matrix, and we have to find 6 eigenvalues out of a 7x7 matrix rather than 3 out of a 4x4... but it's still a lot better than 16 out of a 17x17, and is now getting down to the realm of the fairly tractable.

Although, realistically, what you probably do numerically rather than solving for the eigenvalues, etc. is just directly compute T^n for T=1, 2, 3, ... 100 (or however long it takes for your answer to converge) and report that, bypassing the whole "symbolic" thing entirely.

I think this is getting down to the realm of where I might actually try to write a program to do it; 100 7x7 matrix multiplications is really not that bad, and could probably be done a couple hundred times to get all the partials you need without too unreasonable a performance overhead.

I haven't confirmed this recently, but I believe poison applications are subject to binary resists, and then the ticks can additionally be partially resisted. But further testing of that would probably be advisable.

 

• Aldriana

Upon further contemplation, I don't think you can get away with only having 2 bookkeeping slots due to the necessity of capping poison stacks at 5. I think what you actually have to do is assign 6 new cells, one to track the probability of having 1 stack, one for two stacks, etc. up to 5, and then the 6th to track total stacks applied to date. Unfortunately, this gets us back up to 11 rows, which, while nicer than the 17 we had earlier, is still an unfortunately large amount.

 

Dontmindme

Actually, I need to backtrack some. Let me first state that advanced mathematics is probably not a good idea on a paper napkin at lunch. My original formulation works. I missed a term in the 1+ stack equations. I probably do not have time to explain fully but what I forgot is that when a proc successfully upgrades to a new stack size there is a period that equals one attack interval. So the percentage at stack 0 is relative to stack 1.

Let's define some terms:
Int = Interval between attacks (or essentially 1/v in Aldriana's uptime formula)
Pr = Proc Rate defined as chance to hit * chance to proc DP

So starting immediately after an attack we have at any stack two things that can happen:
We can have a successful proc within 12 seconds.
We fail to successfully proc within 12 seconds.

If we successfully proc we start at the beginning of the next stack. It should be pretty obvious that the chance to proc within 12 seconds is the same regardless of which stack you are on. The Duration here is Int + Average length of time until we get a proc already defined as less than 12 seconds. In the case of 0 stacks, you cycle back to itself just like any proc at another stack size.

If we fail to successfully proc within 12 seconds (stopping just after the final failed proc less than 12 seconds) we start again at 0 stacks. It should be noted that the duration of this cycle is actually Int + the largest multiple of Int less than 12 as the first Int is the time before the first attack.

Ok, going to bed, before I discuss more...

------
I should also add that just getting the relative uptimes at any stack size does not necessarily equate to the procs at a particular stack, but if one assumes they are roughly equivalent the model works. So, my equation does work, just that there may still be room for improvement.

 

• Aldriana

Well, lets see where this approach leads. Let's define two events, E1 and E2, as follows:

E1 = We get a deadly poison proc
E2 = We go 12 seconds without a proc.

From this, we can easily compute two things:

1) The expected time until E1 or E2 happens, which we will denote by T, and
2) The probability that E1 happens before E2, which we will denote by P

As usual, we define Q = 1-P.

Note that the time until the first stack is not the same as T; it is simply the expected time until event E1, rather than the expected time until E1 or E2. We can, of course, compute that duration as well, but that answer is different from T.

However, what we can say is the following: it is *only* possible to get to 2 stacks if we were previously at 1, and the expected time to remain at 2 stacks given that we've gotten there is the same as the expected duration of being at 1 stack, given that we're already there. Hence, we know that D2 = P*D1, D3 = P*D2 = P^2 D1, and D4 = P*D3 = P^3*D1

But the next trick, then, is that we can define D6, D7,... DN (even though you can't reach this number of stacks), which basically represent the circumstance where you have 5 stacks and refresh it once, twice, three times, and so on. Thus, the time we remain at 5 stacks is D5 + D6 + D7 + D8 + ... = D1 * P^4 * (1+P+P^2+P^3+...) = D1*P^4/Q

But now, since we can compute D0 directly using the Mongoose formulation, we know the total time that at least one proc is up, and we know that it equals D1 (1 + P + P^2 + P^3 + P^4/Q) = D1/Q, which allows us to solve for D1 and then the value of all the uptime blocks.

Looks like this actually works for the continuous-poison case - it remains to be seen how well that models that 3-second-tick poison case, but this should at least give us a better estimate. Lets start plugging in numbers.

As usual, define
v=# of attacks per second
p=probability that a given attack procs
q=1-p.

Now, by our uptime formula we derived for Mongoose, Up = 1-q^{12v}, so D0 = q^{12v}.
Similarly, we find that Q = q^{12v}; hence D0 = Q. Thus, Q + D1/Q = 1, so D1 = Q(Q-1) = PQ
So we have:
D0 = Q
D1 = PQ
D2 = P^2 Q
D3 = P^3 Q
D4 = P^4 Q
D5 = P^5

Thus, average stacks is:
PQ + 2QP^2 + 3QP^3 + 4QP^4 + 5P^5

which telescopes down to

P + P^2 + P^3 + P^4 + P^5

more concisely written as

P(1-P^5)/Q

Substituting in Q = (1-p)^{12v}, we have:

Expected stacks = (1-(1-p)^{12v})*(1-(1-(1-p)^{12v})^5)/((1-p)^{12v})

Now, the moment of truth: does this answer make *any* sense whatsoever?

Well, grabbing numbers for my current gear out of the Rogue Gear Spreadsheet, we have that for my optimal cycle, and typical raid buffs, using DP only on OH, v = 1.12 and p = .921 * .3 * .83 = .229, we then have Expected stacks = 4.565, versus the spreadsheet's currently predicted value of 4.58 - so we're decidedly in the right ballpark. Whether it's true in general will require more sanity testing and some long simulation runs... but we're close.

Next up: same problem with poison quantized to ticks rather than being a simple 12 second buff.