
I have been have an ongoing discussion with Ermad on various aspects of the Holy Paladin model in Rawr. One thing that popped out is it appears that the mana return calculations on Je'Tze's Bell is incorrect (Ermad said he found and correct the error
in Figurine  Sapphire Owl). I'm actually concerned that this problem could be much larger than even that in Rawr (effecting all mana procs). So here are the details.
I experimented by removing my Je'Tze's Bell. To recreate, load Darion from Hellscream on 2.2.4. Then reduce the fight time from 7 minutes to 2 minutes (leave all other options as is). When I removed the trinket (basically leaving
the slot empty), the mana pool dropped from 60587 to 59896. The delta being 691. 691? That is a weird number. Bottom line in a two minute fight it is impossible for the trinket to return more than 600 mana. It could be less 
300 or even 0 if you spell cast's are low and/or you are incredibly unlucky. But it can't Proc more than twice.
Ermad told me there was considerable complex math that very accurrately calculated the average procs. Here was my response:
Ermad  thank you for you reply. I'm concerned by your answers though. You are implying a lot of 'complex math' to 'more accurately' judge how often it will proc on average. With all due respect  there is no complex math here.
The amount of time it takes to proc can be calculated and in the end you get a discrete set of 'procs'. Not a continuous stream of 'averaged' mana. My napkin math spreadsheet (complex math gives me hives) has these equations:
mana returned from Sapphire Owl useage = (int((Fight time in sec  60)/300)+1)*2340
so if you have a 60 sec fight you get 1 usage (yeah  I know  it takes 12 sec for the mana return to finish  I simplified)
if you have a 300 sec fight you get 1 usage = 2340 mana
if you have a 420 sec fight you get 2 usages = 4680 mana
For the Je'Tze's Bell proc's I do the same sort of thing:
mana returned from Je'Tze's Bell procs = (int((fight time  (fight time / # of spells cast) / 10%)) / ((fight time / # of spells cast) / 10% + cool down)) + 1) * mana returned
so if you have a 60 sec fight you get 1 proc = 300 mana (a proc at approximately 15 sec's give your method)
if you have a 300 sec fight you get 5 procs = 1500 mana (a proc at 15, 75, 135, 195, 255)
Seem reasonable? Numbers like 691 mana scare the crap out of me because it probably means you are 'averaging' the mana returned across the fight time and that's just wrong.

Can the owner of the proc code please comment? Thank you.


Developer
May 28, 2009 at 6:35 PM

IED has 5% proc, 15s ICD.
In a 60 sec fight Je'Tze's bell is more likely to proc twice, returning more than the 300 mana you'd expect.
In a 2 minute fight where it procs in avg every 52 seconds, you can expect to see it proc at
7 seconds, 59 seconds, 111 seconds, or 900/120*5 = 37.5mp5. However the trinket modelling is slightly more accurate than this.



You are arbitrarily deriving the average proc time for the trinket as 1 minute. There is no way to say that at all without knowledge of Trigger Interval (aka how often do you do an action that can proc the trinket). Compare two characters one who casts FoL
the whole time, and one the casts HL the whole time. The one who casts FoL the whole time will gain more mana from Jet'zes bell since it has a lower average cast time, so it takes a shorter amount of time on average to get a proc.
You are also trying to get a discrete proc times for things that have probabilities and chances of procing. Say if some theoretical proc in a theoretical fight has a 50% chance of procing twice, and 50% chance of procing thrice, how should it be
valued? You would value as either 2 or 3 procs, yet valuing it as 2.5 procs would be much more accurate.



Let me start by apologizing. The Insightful Earthsiege Diamond does have a 15 sec cooldown  not 45 sec I put above. Complete miss on my part and made even worse by my having modelled it correctly in my spreadsheet and then writing an incorrect
post.
With that said I don't understand your answer. I'm not arbitrarily deriving anything. I'm using the output from your tool to calculate the average time to proc. You guys seem to be making this more complicated that it has to be. You
managed to modeled Divine plea correctly. This has the exact same concept with a bit more complexity dealing with proc chance. ie: you have a discrete bump of mana at some set time and if the fight time says you only get two procs  you get
two procs. Nothing about inventing a partial proc to be 'statistically correct across time'.
Let me come back at this in a different direction. Are you saying that the proc chance isn't 10% for the Je'Tze's Bell? What complicated math am I missing. Doesn't a 10% chance mean that on average you need 10 spell casts to proc (noticed
the 'on average' part  critical for many of our assumptions when modeling). For a 2 minute fight, the tool was using HL completely and with an 89% activity setting I assumed 1.5 sec average cast time was reasonable. This means on average
you get a proc at 15 sec (1.5 sec / 0.1).
So on average you have this timeline:
0:00 Start fight
0:15 Have cast 10 spells, on average, trinket procs here. yes  it could have proc'd at 0:00 or sometime around never, but average is at 15 sec.
1:00 45 sec cool down is up and now the trinket can proc again
1:15 Have cast another 10 spells, on average trinket procs here.
2:00 45 sec cool down is up and now the trinket can proc again
Tell me the average time per spell is 1 sec and I'll give you a different timeline (yielding 3 procs instead of 2). Tell me the average time per spell is 2 sec and I'll give you a different timeline (yielding 2 procs  you don't drop to one unless
you have an incredibly slow cast rate).
What am I missing?


May 28, 2009 at 7:29 PM
Edited May 28, 2009 at 7:34 PM

Divine Plea has nothing like these procs. You can choose when you hit Divine Plea, these procs happens at a random time after the cooldown comes up.
Even if you are using just Holy Light, the Trigger Interval isn't just HL cast time. You have the short GCD casts of SS/BoL/HS, along with downtime associated with activity. I am on my mac so I don't have Rawr in front of me at the moment, but the average
cast is almost surely not 1.5 seconds.
Kavan (or someone else) should comment more on the math behind determining proc uptime, since he is one that coded it in.



Please  I made it very clear I was talking about discrete bumps of mana coming in over a given time. Let me come back to the statistics part. You seem to be hung up on the 10% proc chance. I realize that if you try this again and again
as an experiment. You would get a range of proc's  bell shaped curve with the high point at the 10 cast point and a very long tail out in time given you do enough 'experiments'. But on average  you get a proc after 10 casts. It can happen
earlier, it can happen later....but on average it happens at the 10 cast point...Correct?


Developer
May 28, 2009 at 8:07 PM

10% chance doesn't mean 100% after 10 casts. Although that would really simplify things. 10% chance just means you have a 90% chance to not proc it. And since the outcome of the previous chance doesnt' affect the next chance (ignoring ICD), that means after
2 casts, you have a 0.9*0.9 = 0.81% chance to not proc it. So basically, chance to proc after X casts is 1  (1  Chance)^X. Then you gotta consider the ICD and that makes things even more complex. Also you gotta adjust for the average length of each cast
to complete and how often you cast.
Basically, Kavan made a class that handles all this for us and produces fast and accurate results (given that we model authors feed it the right values).


Coordinator
May 28, 2009 at 8:38 PM

Well everything is documented in code, but here is the derivation for computation of average number of procs in a fight of a given length. In the derivation all time durations are expressed in terms of trigger intervals.
derivation from recurrence relation
Procs[n] := average number of procs given fight length n
p := proc rate
q := 1p
C := Cooldown / triggerInterval (assume C = 1 if cooldown less than trigger interval)
Procs[n] = p + p * Procs[nC] + q * Procs[n1]
split the function definition in segments of size C and solve each segment separately
that way the recurrence is only nonhomogeneous first order
Procs[n,k] = p + p * Procs[n,k1] + q * Procs[n1,k]
for k = 0 solve
Procs[n,0] = p + q * Procs[n1,0]
Procs[0,0] = 0
solution is
Procs[n;0] = 1  q^n
for further segments let k be the previous segment and Procs(n)=Procs[n,k] the closed form
solution for previous segment
the homogeneous part has solution of form A + B * q^n
the particular solution is obtained using method of undetermined coefficient using the
form of n * P(n) * q^n, where P is polynomial of order k
we can more generally just set the form of Procs2(n)=Procs[n,k+1] as
Procs2(n):=q^n*sum(A[i] * n^i, i, 0, k+1)+sum(B[i]*n^i,i,0,k+1);
using the recurrence
eq: Procs2(n) = p + p * Procs(n) + q * Procs2(n1);
we compute the missing coefficients
splitqn(eq):=makelist(ratcoef(eq,q^n,i),i,0,1);
spliteq(eq,var,order):=makelist(ratcoef(eq,var,i),i,0,order);
eqlist: flatten(map(splitqn,makelist(ratcoef(eq,n,i),i,0,k+1)));
ev (tellsimp (0^0, 1), simp: false);
solution: solve(append(eqlist,[Procs2(0)=Procs(C)]),append(makelist(A[i],i,0,k+1),makelist(B[i],i,0,k+1)))[1];
Procs2s : subst(solution,Procs2(n));
Procs2s : ratsubst(Q,q^C,facsum(subst(q,1p,ratsimp(subst(1p,q,Procs2s))),q^n));
for the first few k we obtain the following (Q := q^C)
Procs[n;0] = 1  q^n
Procs[n;1] = 2  (1 + Q + p * n) * q^n
Procs[n;2] = 3  (1 + Q + Q^2 + p * (n + (C + n)*Q) + p^2 * n*(n+1)/2) * q^n
Procs[n;3] = 4  (1 + Q + Q^2 + Q^3 + p * (n + (C + n)*Q + (2*C + n)*Q^2) + p^2 * ((C^2+(2*n+1)*C+n^2+n)*Q+n^2+n)/2 + p^3 * (n*(n+1)*(n+2))/3!) * q^n
analyzing the form we can obtain the following generalization
Procs(n,k):=k+1sum(sum(binomial(C*j+n+i1,i)*q^(C*j+n)*p^i,j,0,ki),i,0,k);
which can be verified with the recurrence
rearranging the sumation
Procs(n,k):=k+1sum(q^(C*j+n)*sum(binomial(C*j+n+i1,i)*p^i,i,0,kj),j,0,k);
we inspect the inner sum which has the following form
G(K,kj,p):=sum(binomial(K+i,i)*p^i*(1p)^K,i,0,kj);
for K = 0 we get
sum(p^i,i,0,kj)
which can be evaluated to
G[0](kj,p):=(1p^(kj1))/(1p);
we can express G in terms of G with lower K as follows
G[K+1](kj,p)=(1p)^K*sum((1p)*p^i*binomial(K+i+1,i),i,0,kj);
G[K+1](kj,p)=((1p)^K/(K+1)!*(sum((p^i*(K+i+1)*(K+i)!)/i!,i,0,kj)sum(i*(p^i*(K+i)!)/i!,i,1,kj+1)));
G[K+1](kj,p)=sum((1p)^K/K!*(p^i*(K+i)!)/i!,i,0,kj)(1p)^K/(K+1)!*(kj+1)*(p^(kj+1)*(K+kj+1)!)/(kj+1)!;
G[K+1](kj,p)=G[K](kj,p)(1p)^K/(K+1)!*(p^(kj+1)*(K+kj+1)!)/kj!;
G[K+1](kj,p)=G[K](kj,p)(1p)^K*p^(kj+1)*binomial(K+kj+1,kj);
this gives us an alternative formulation of G
G2(K,kj,p):=(1p^(kj+1))/(1p)sum((1p)^i*p^(kj+1)*binomial(i+kj+1,kj),i,0,K1);
we can now rephrase the Procs function using this to get
Procs3(n,k):=k+1(1p)*sum(G2(C*j+n1,kj,p),j,0,k);
=sum(p^(kj+1),j,0,k)+sum(sum(binomial(kj+i+1,kj)*(1p)^(i+1),i,0,j*C+n2)*p^(kj+1),j,0,k);
we observe that we can express the inner expression in terms of negative binomial
Procs3(n,k):=sum(sum(binomial(r1+i,r1)*(1p)^(i),i,0,k*C(r1)*C+n1)*p^r,r,1,k+1);
Procs3(n,k)=sum(sum(Pr(NegBin(r,p)=i),i,0,k*C(r1)*C+n1),r,1,k+1);
using the cumulative probability density for negative binomial we can express Procs as
P(x):=sum(I[p](r+1,xr*C),r,0,floor(x/C))
where I[p] is incomplete beta function


Developer
May 28, 2009 at 10:26 PM

Let me quote one of the paragraphs:
Playing the instant lottery
Probabilities are based on longterm percentages (over thousands of trials), so when you apply them to a group, the group has to be large enough (the larger the better, but at least 1,500 or so items or individuals) for the probabilities to really apply. Here's
an example where longterm interpretation makes sense in place of shortterm interpretation. Suppose the chance of winning a prize in an instant lottery game is 1/10, or 10 percent. This probability means that in the long term (over thousands of tickets),
10 percent of all instant lottery tickets purchased for this game will win a prize, and 90 percent won't. It doesn't mean that if you buy 10 tickets, one of them will automatically win.
If you buy many sets of 10 tickets, on average, 10 percent of your tickets will win, but sometimes a group of 10 has multiple winners, and sometimes it has no winners. The winners are mixed up amongst the total population of tickets. If you buy exactly 10 tickets,
each with a 10 percent chance of winning, you might expect a high chance of winning at least one prize.
But the chance of you winning at least one prize with those 10 tickets is actually only 65 percent, and the chance of winning nothing is 35 percent.
Add on the following now:
After winning a ticket, you have to buy another 20 tickets before you have a chance at winning again. Thats how procs with an ICD would work. Trust Kavan :)


May 28, 2009 at 11:10 PM
Edited May 29, 2009 at 12:37 AM

Let me see if I understand correctly.
If you have a 10% of success. And you try that 'game' ie: cast the spell until success. You get for each success a number of tries. That number is somewhere between 1 and infinity. For pratical purposes probably between
1 and 50 or so. So you can represent that this way.
Try #1  5 casts before success
Try #2  13 casts before success
Try #3  1 cast before success
Try #4  8 casts before success
etc
Now if you try an infinite number of times my contention is that the average number of casts is 10 to reach 'success'. Is this not correct? I understand that if 100 'tries' you may have an average of 9.5 or 10.7 or something like that.
But as the number of tries gets bigger and bigger you approach 10. When you hit infinity  it's for all pratical purposes 10.
Correct?



Ah  thought Kavan might want to weigh in. Sorry. So if we have agreed to 10 casts for 'on average' a proc success  can't we now take the next step? Your tool calculates behind the scenes the number of casts for every spell. It would
be simple to add up all the casts and divide into the fight length to get the average time between casts  correct? With that number and the agreement on 10 casts we now have the number of seconds between starting to try and proc 'on average'.
In my case I asserted 1.5 sec per cast for 'on average' 15 secs from start to procing the trinket. Correct?


Coordinator
May 29, 2009 at 12:51 AM

The main thing to observe here is that when you have a limited number of tries (i.e. fight duration) it's possible that event will never happen. Let's have a random variable X which represents number of tries before we get a success. This variable has negative
binomial distribution. The mean of X with 10% chance of success is indeed 10. But that's only valid if you're willing to wait till infinity. When we're limited with fight duration what you need is probability that you'll get at least one proc before fight
ends, that is Pr(X < fightDuration). Now this would be if we were only interested in one proc.
Now let's have NegBin(r, p) be negative binomial variable with parameter r and chance of success p. This represents the number of tries before we get r successes (check
http://en.wikipedia.org/wiki/Negative_binomial_distribution for math refresher).
Let Y be a random variable representing number of procs in fight of given length. Expected value for Y is by definition E(Y) = sum_i=1..inf i * Pr(Y = i) = sum_i=1..inf i * (Pr(NegBin(i, p) < fightDuration)  Pr(NegBin(i+1, p) < fightDuration)
= sum_i=1..inf Pr(NegBin(i, p) < fightDuration)
This was without internal cooldowns. Now you can generalize this with a leap of faith to E(Y) = sum_i=1..inf Pr(NegBin(i, p) < fightDuration  (i  1) * cooldown) which is derived in more detail above.


May 29, 2009 at 1:21 AM
Edited May 29, 2009 at 1:42 AM

I believe I understand what you are trying to accomplish. But I'll try to say this in the nicest way. I think you are adding complexity to the point of the model giving bad results. Another way to handle the uncertainty of when you proc
'successfully' would be to put an error bar on the proc time. perhaps it's 10 casts +/ 3 casts. Then model it such that you still get discrete bumps of mana. Right now you get something completely wrong from a fight perspective. You
simply can't ever get 691 mana in a 2 minute fight. But you could get 300 (low chance) or 600 (high chance) or 900 (low chance). In a longer fight you could get 300 (very low chance), 600 (low chance), and 900 (high chance), maybe 1200 (low chance).
This seems more supportable than the 691 mana from the current model.


Developer
May 29, 2009 at 1:35 AM

So basically what you are saying is, 50% of the fights you get 900.
30% of the time you get 600.
20% of the time you get 300.
900*.5 + 600*.3 + 300*.2 = 690.
Discrete bumps of mana does not really show you your average results.



Frankly  I believe it is debatable whether it really is more accurate to model it the way Rawr is. In effect you are putting error bars on the timing of the proc. I'm not a statistics expert so I accept at face value the math is correct.
But essentially you are saying given a fight of X length. The trinket could proc as few as 0 times and as many as (X in sec) / 45 + 1. Then you do some fancing math that says it procs 2.3 times on average. I'll accept that this is true
but say say given an infinite number of fights  on average  you will proc not 0 times or (X in sec) / 45 +1. But you will proc exactly (INT(X  (X / # of spells cast) / 10%)) / ((X / # of spells cast) / 10% + cool down)) + 1).
Oh well  broken record. I'm curious why you aren't consistent in using this methodology?
You could have just as easily done the same thing for Divine Plea. I realize the user puts in a cool down  although I suspect most don't actually mess with the settings. But there is no alarm on their desk that says  it's been
two minutes  proc divine plea  and then every user automagically procs at exactly 2 minutes. There are error bars on that as well. Why don't you put some statistics around that and then 'average' the mana returned? Essentially the
same principal. Not that I'm asking for it  I think you have Divine plea correct and have become 'too complex' for procing trinkets. But then  this is an engineer talking who believes perfection is the enemy of the good.


Coordinator
May 29, 2009 at 6:56 PM

What you're computing is not average. The number we compute is average. What you're computing might be close to a median, but it's definitely not average over infinite number of fights. We're not putting any error bars anywhere, we're not using any deviation,
just pure exact average. Let me give you an example why average is better than median. With median when your haste slightly changes and your trigger intervals get slightly shorter the median will remain most likely the same, it'll have a very steplike behavior.
Average on the other hand is very smooth. For purposes of evaluating gear upgrades smooth functions are a lot more appropriate.



I'm not sure your way is much 'smoother' than what I advocated. You have divided your time slices in Rawr into 0.5 minute increments. So every time the user increments that  there is a 'jump' in mana. Caused by lots of things
like Mp5  that alone for me is 1800 mana for 30 sec. And yes  including your recalculation of the procs of this trinket, IED, and goodness knows what else. What I was advocating would also cause 'jumps' in the mana pool every 30 sec  but in
the scheme of things I don't believe it would be noticable.
And can I poke at the average part? Given a 10% chance to proc with a 45 sec cool down and a 1.5 sec average cast time  a pure average would say 1.5 / 0.1 = 15 + 45 = 60 secs per proc. That is 300 / 60 = 5 mana per second. In a 120 sec
fight you would get 600 mana from the trinket. In a 130 sec fight the number would be 650 mana. That would seem to be a pure average. I don't believe this is what you are doing.


Coordinator
May 29, 2009 at 7:56 PM

Man you are stubbron for someone that admits he's not too familiar with probability. Ok so by your logic in a fight that lasts 30 seconds are you saying that average is 5 mps * 30 = 150 mana? Not true. In 30 seconds you have 30 / 1.5 = 20 casts. There is
1  0.9 ^ 20 = 87.84% chance that you'll get a proc. So the average is 264 mana.
I'm not sure where you get the 0.5 minute from. If you're referring to fight segmentation in mage model that is completely different and has no effect on any kind of jumps. And yes it is smoother.



Sorry to jump in, but hopefully this will help:
Kavan: I'm pretty sure he's saying he does NOT like the averaged idea. So debating how said average is calculated isn't addressing that.
Darion: You really should use the averaged value :)
You cannot simply assume 1 proc per minute as you are using and get accurate results. Kevan's math has shown how, especially in short fights, the assumption of exactly 10 casts to proc is not correct.
And if you really do not want an averaged value, what would you want to see instead?
I'd personally find it more confusing to get a readout like:
30% chance: mana pool = 50000
22.4% chance: mana pool = 50300
35.7% chance: mana pool = 50600
11.9% chance: mana pool = 50900
(I picked random numbers btw, so don't use them for anyhting)


Coordinator
May 29, 2009 at 8:40 PM

Well the underlying question is a lot more fundamental. It's the question of what are we optimizing. Are we optimizing for worst case situation, are we optimizing for most likely situation or are we optimizing for average situation. You could argue for each
of them to have a place depending on what you wanted to know. I would argue that for purposes of evaluating gear upgrades optimizing average situation is the most appropriate for the reasons I mentioned above.



I'd mostly agree. This derailing from paly proc math, but figure for things like rotation, even if you use average case to determine expected DPS (which I agree with), I do sometimes wish for a worstcase printout. For example if every attack
I do fails to crit and my combo point generation is screwed up, I'd like to know what's my best case option to get back on track. Do I need to temporarily adjust or not? Or the obvious case for tanks where people favor uncritability to prevent
worst case spikes over average mitigation. But in general case, exact size of any given hit or power is irrelevant and the average you can do over a series of raid encounters is most important.



Kavan  thank you for your time. Two comments  the first is 0.5 minutes is the discrete value picked by the Healadin Module in Rawr for fight length control. You can select 1, 1.5, 2, 2.5, etc. So you have built in mana jumps that
cause the idea of smoothing for gear selection to break apart. My point was that the 'jump' caused by positioning of a 300 mana proc paled in comparison to a divine plea proc of 7.5k mana, or a Mp5 gain of 1.8k in that same 30 sec discontinuity built
into the Rawr model. I wasn't trying to argue mine was better at smoothing  just that either way really made no difference in the scheme of things because they are swamped out by much bigger mana changes in that 30 seconds.
And yes  probability isn't my area of expertise. Took a couple of classes in college and hated it  aced it of course but pegging a class and truly understanding is always two different things. Was much better at calculus which is bread and
butter for electrical engineers (at least in college  most is forgetten in the working world).
And yes again, I understand your example  it gets much, more interesting at time 0:45 where you can still have probability that it hasn't procced at all yet. And at the same time start adding in a chance that not only has it procc'd the first
time. It's starting to have a probability of proccing the 2nd time. 1:30 gets even more exciting. etc. I get all that conceptually (at least I think I do :). I just don't believe the complexity that you are adding does much for actually
selecting gear.
Can I ask a quick question on output? I just walked the fight time from 2 minutes to 7 minutes (0.5 minute increments of course). And then compared Rawr output to my spreadsheet using the napkin math 'on average' method. I assumed 1.5 sec
cast time in my spreadsheet which sort of seems built into Ermad's algorithm (I believe it to be just a smidge less  perhaps 1.4  1.45 or so). Here is the result:
2 minutes 600 691
2.5 minutes 900 838.4
3 minunte 900 995.93
3.5 minutes 1200 1142.64
4 minutes 1200 1297.72
4.5 minutes 1500 1460.04
5 minutes 1500 1625.99
5.5 minutes 1800 1776.99
6 minutes 1800 1940.13
6.5 minutes 2100 2096.13
7 minutes 2100 2255.4
So what we are talking about is in the 30 sec increments hard coded into Rawr  you calculate the average proc to be an additional 156 mana every 30 secs (average from above). Mine proces for an average increase of 300 mana every 60
seconds.
So the question  the the average 156 increase due to the nature of your algorithm  or is it pure average spell time? If you actually write out the deltas above  you see the 156 is growing. Starting out at around 150 and ending up closer
to 160.


May 29, 2009 at 9:05 PM
Edited May 29, 2009 at 9:11 PM

.5 is just the change that happens when you click on the buttons in the control. You can enter in your own number manually (though I believe it gets rounded to .1).
You can't really compare the the mana returns since you admitidly have no idea what the average cast time in Rawr. Part of the reason it isn't printed out is because it uses an interative method to try to get a more accurate value on procs. Lets say you
do all of your proc calculations assuming you have a 1.5 second cast time, and determine you gain X mana from them. Now that extra mana is going to change your average spell cast time, which in turn changes the value of procs, which in turn changes spell cast
time, and it keeps repeating until it eventually gets out to a consistent number. Basically Rawr.Healadin does this loop a few times to get more accurate results.



Kavan  thanks for the graph. It matches in the beginning exactly as I would suspect. You see the rapidly rising chance for success in the first proc and then at time 45 the same rapidly rising for the 2nd proc merged with the continuing of the
1st proc. Then after the probability for the 3 and 4 proc kicks in  it all gets completely blurred together. Cool stuff. It's interesting that the 'on average method' I advocated is always 0.3 to 0.4 proc's behind. I'm sure there is
math to explain it. But no need for more conversation. I understand, have enjoyed the conversation, and will continue to use both methods where I feel is needed. Thank you.
Ermad  thank you for the tip of actually typing in a value. Lol...I get too use to a mouse and clicking. As for displaying the average cast time  I know you have all the information in the model. After you have done all your iterations
 you calculate the amount of mana needed to cast all those spells (displayed on the mana usage breakdown). You can't do that without a number for each spell. You have the time spent in the rotation for all the spells (displayed on the rotation
breakdown). Again you need the numbers of spells to do that. Adding up all the spells and dividing by the fight time would give you a great approximation of the number of spells per second (with the realization that divine plea, judgements,
sacred shield, divine illumination puts more 'weight' in certain parts of the cast time line). I suspect that this is one of the inputs to Kavan's subroutine and you have just chosen not to display that to the user.



The first iteration uses 1.5sec to start with, once it is done it calculates a few different values. Average time inbetween spell cast (including everything), average time between heal, and average time between heal crit, since different procs use different
values. It then uses these values to determine the value of the procs for the next interation.

