it takes frequency (probability) and strength (squish) into account.

for commanders, for shadow. decreasing defense, shield and absorb by 100 points increases spike by the following amounts:

a

base spike: 0.022021301

-100 shield spike 0.022244571

-100 absorb spike: 0.022120985

-100 defense spike: 0.02208923

spike difference for 100 shield : 0.000223271

spike difference for 100 absorb : 9.96843E-05

spike difference for 100 defense: 6.7929E-05

spike= sum(probability[ij]*(squish[ij] - squish)^2)

where i runs over kw_named, kw_bland, kf and ef (i thought there was ew damage, but i guess not)

and j runs over defended, resisted, shielded and full hit. (see my thread for variables)

Wouldn't the following make spike slightly more useful?

spike= sum(probability[ij]*sqrt(squish[ij]^2 - squish^2))

Basically using RMS rather than straight variance. The results of this calculation would be a direct standard deviation calculation on mitigation, piecewise-weighted by the disjoint probability of each case. The result would (I believe) be a value that we could use as a conventional standard deviation, which is less biased than a variance. (in particular, I think this will exhibit less pronounced skew against defense. Defense will still be less exciting than shield for spike optimization, but I believe RMS will penalize it less than simply difference squared.

Another thing to think about with these sorts of calculations… I've never been particularly happy with how our best efforts for spike calculation (and, to be clear, dipstik's math really is best-of-the-best here) fail to take into account split attacks and the like. The canonical example here of course being pre-nerf NiM Oasis with assassin tanks. Both RMS and difference squared spike calculations naturally predict the spikiness of pre-2.5 assassin tanks, but they fail to distinguish between the "coin flip death" of pre-nerf Oasis and the "generally survivable but still scary" of post-nerf. Here again, defense is unduly penalized by the fact that we do not take this variable into account.

pray tell, what is the new swing timer? since im doing all per boss i guess i could use per boss swing timer info... if anyone has those...

I'm using a swing timer of 1/(15/18). This is basically a cheap hack based on the very high-level observation that the vast majority of fights in the new content can and will exhaust all 18 Kinetic Ward stacks over the course of the 15 second duration. This swing timer does generate a value for Kinetic Bulwark which appears to be predictive, so I'm relatively happy using it. I'd love something more authoritative though.

One thing to note here is that this swing timer represents a massive increase over previous content. Specifically, 35% faster attacks! This increase and rough order of magnitude also bears out well with what I see in combat and generally in my logs, so it represents a reasonable check on my cheater number from above. Still interesting.

isnt it a 18 second duration with set bonus?

and, am i suppose to take the real part if squish[ij] is less than squish? or the modulus?

isnt it a 18 second duration with set bonus?

It's a 23 second duration with the set bonus, but the cooldown is 15 seconds. I'm calibrating off of the fact that I will often lose all 18 stacks fast enough that just hitting Kinetic Ward on cooldown is actually optimal. And remember that shield chance is not 100% and defense chance is not 0%, thus the swing timer is going to be quite a bit higher than the value calculated from direct Kinetic Ward usage. This is why, despite the fact that losing all 18 stacks is not a consistent thing, I still feel justified in using 1.2/sec as the net K/E swing timer.

and, am i suppose to take the real part if squish[ij] is less than squish? or the modulus?

Ah… Yeah that was screwy. I basically distributed the squaring in the wrong direction. This might be more reasonable:

spike= sqrt(sum(probability[ij]*(squish[ij] - squish)^2))

Basically I'm just trying to get the square root back in here, since squaring the variance and using that as an absolute coefficient strikes me as wrong. The quirky thing I see about the above proposal is that the probability scalar is distributed into the sum. I think I have to do this by definition, but it's a little weird.

Edit: Upon some further reflect in between debugging an unrelated project, the probability[ij] term actually makes perfect sense where it is. Basically, we're computing the RMS of the different cases, but it's a weighted mean with the coefficients normalized to sum to 1 (I'm assuming sum(probability[ij]) = 1; if it doesn't, then…uh, I have no idea what you would be doing in that case).

So yeah, I think this is the more accurate term. The original spike would be fine as a relative coefficient (i.e. optimizing for it will produce the same results as optimizing for my revised spike), but the new spike has more intuitive values and can be used in composition with other statistical metrics more directly.

Edit 2: Consider spike' to be my rooted version of spike. Terminology note: spike is weighted sigma squared, so we're right in line with a reasonable statistical framework. Let's think about the following idea…

As step one, rather than showing tank survivability in terms of absolute mitigation (i.e. squish), why don't we display in the following form:

squish ± spike'

This gives a direct notion of how much spikiness a tank can expect in terms of percentages that can be summed into their mitigation. I think most people with a decent statistical grounding should be able to understand that presentation and derive strictly more value out of it than our current "single number form". Furthermore, we can perform some interesting optimizations now that we have a real weighted sigma.

For example, we could optimize for squish - spike' * k, where k is some reasonable coefficient. I would suggest that three standard deviations is probably sufficient for anyone, but I would also be fine with going closer to 2. This is an assumption on the part of the theory crafters (us) to be sure, in that we are making a hard assumption about how much variance is "acceptable", but thinking in terms of the standard deviation it seems perfectly reasonable.

Another exciting thing that we can do here is scale the spike' value by DtPS to actually include a survivability value for endurance!! Every big heal in the game is between 2 and 2.5 seconds, so let's consider a "spike window" to be double that, at 5 seconds. 5 * dtps * (squish + spike' * k) is the absolute magnitude of the k standard deviations worst-case spike healing scenario. Divide that by total HP and you get the worst-case scenario as an easy-to-consume percentage.

Now my very first thought upon deriving the above was to try to figure out how to compose it with squish, but notice that squish is already part of the derivation! In other words, this is basically a single, master statistic which tanks can use to optimize endurance and mitigation as a cohesive package, dependent on the value of k. I think we have yet to see exactly what sort of results this would churn out, but intuitively it seems very promising.

i used to calc squish +/- spike, but the coverage factor k and applying to endurance i never thought about.

note that choosing the k factor, is the same as choosing the weight of squish in the optimization.

dtps*window*(squish+k*std) = dtps*window*k*(squish/k + std). everything outside the parenthesis is just a scalar. this is very much like taking 0.5*squish and 1 for std, and normalizing we get 0.333*squish+0.666*std...

ill redo everything using the sqrt of spike and call that spike from now on. it is more useful.

note that choosing the k factor, is the same as choosing the weight of squish in the optimization.

Indeed it is. Though, I think that this form gives us scalars (namely k) which have more intuitive meaning. Since these are subjective tuning parameters, it's pretty important that we have them conceptually grounded in something that we can comprehend easily.

In other news, I ran the survivability and stddev numbers for every tank in full mitigation Revanite, and the results are a little surprising. Assuming I didn't make any errors:

{High-><|shadow->{0.699422,0.312593},guardian->{0.696596,0.336262},vanguard->{0.673705,0.363111}|>,
Mid-><|shadow->{0.667891,0.297257},guardian->{0.678768,0.33094},vanguard->{0.647002,0.359878}|>,
Low-><|shadow->{0.661643,0.281025},guardian->{0.662052,0.305025},vanguard->{0.653382,0.351558}|>,
Average-><|shadow->{0.677605,0.296402},guardian->{0.679006,0.325637},vanguard->{0.660035,0.356973}|>}

So…shadows have a lower weighted standard deviation than the other tanks across the board? That would completely flip all of our assumptions on end.

it seems worst case scenario for 5 seconds of damage is typically not as bad as 5 seconds of damage taken at 2 sigma from base squish.

still seeing PTs more spikey than shadows though...

updated my numbers, had a HUGE bug in general, and fixed up the spike math.

i kind of want to optimize such that spike and squish are even... but i think the best option would be, if people are having a hard time with a fight, and they think it is spike killing them, set the coefficient for spike to 1 and the coefficient for squish to zero in x*squish+y*spike, where x+y=1. Or, if they think its steady damage killing them, they do as we do now, and set x to 1 and y to zero. or if each fight had a "spike matters" term between 0 and 1 that is set for each fight...

it seems worst case scenario for 5 seconds of damage is typically not as bad as 5 seconds of damage taken at 2 sigma from base squish.

 

still seeing PTs more spikey than shadows though...

I thought that was weird too, until I did this: http://imgur.com/qbynKYY.png

What you're looking at is the probability density function for each tank, centered on their survivability and with the standard deviation computed with our spike function (note that the y axis isn't a probability, so the fact that it goes above 1 is not wrong). This looked suspicious to me for a while, and then I stared at it for a while.

The narrowness of the shadow graph indicates that all of its mitigation cases are tightly clustered around the mean, so the probability of being outside that bound is very low. However, that doesn't mean that outliers don't exist. Outliers happen even in shadow mitigation, and they aren't captured by standard deviation. The outliers are what people remember though, and they contrast so strongly with the far-more-common cases near the mean that people notice them all the more.

Vanguards have more evenly distributed. This means that they tend to have more mitigation cases that are further away from their mean (positive and negative). However, because these sorts of fluctuations are so common, perceptually they seem just like part of the package. Thus, when Vanguards hit their really crazy outliers, it's less of a contrast from their normal mode of operation.

So by some definitions, Vanguards are more spiky than Shadows, but they aren't more spiky by the definition that most people subscribe to. The definition that most people subscribe to isn't captured by standard deviation, because the crazy outliers are just smoothed over.

i kind of want to optimize such that spike and squish are even... but i think the best option would be, if people are having a hard time with a fight, and they think it is spike killing them, set the coefficient for spike to 1 and the coefficient for squish to zero in x*squish+y*spike, where x+y=1. Or, if they think its steady damage killing them, they do as we do now, and set x to 1 and y to zero. or if each fight had a "spike matters" term between 0 and 1 that is set for each fight...

Interesting idea. Still thinking along those lines…

here is a graph for commanders in fuill revanite gear.

http://imgur.com/6taSF4A

note how the pt goes out the furthest, largest 100% interval over squish. the pt has 2 points with lower squish compared to the sin, at the highest probabilities, while the sin takes less than the pt at the low probabilities. the jugg seems very smooth here. i think the psychological aspect you are speaking to would pertain to the variation in probability, or the height of the graph. note how there is a dramatic uptick of the sin taking more damage at the end of the curve. the other two tanks have a smoother profile where the tanks are most susceptible.

there is also something about the average jump in squish between consecutive points. the sin seems to have a greater distance between consecutive squish values than the other tanks

something else i noticed, looking at the numbers for x=0 to x=1 a few posts back, i noticed that the base squish starts to see less returns for letting spike matter, so to speak. one could look at the base squish, and see that at around x=.3 (which would be around 2 sigma cutoff) the squish gains begin to dwindle down

heres one for the returned

http://imgur.com/iRvEYZJ\

it seems that non internal/elemental damage is very predictable, but the peak at the end, if the healers are not anticipating it, will be very dramatic. high squish and high probability.

One thing i noticed is that in all 3 tankstats Juggernauts and pts have mostly an absorb rating egual to their shieldrating. Sometimes shieldrating is even higher than absorbrating. Assasin tanks however have an higher absorbrating than shieldrating not only in FT+KE fights but also in MR+KE fights. The first reason seems reasonable as there is a minimum shieldrating with 198 enhancements. The second reason is to decrease squishiness. Assasins need a higher absorb rating than Juggernauts to receive an equal squishiness because the Juggernaut has more armour. As you can't negate spikes because shieldrating can not reach 100% there is a certain DR when reducing squishines i.e. going for more absorb is more important than reducing spikiness i.e. increasing shield.

The question is, does an Assasin die because he receives one large hit or does he die because he receives two little less large hits in a row? My guess would be the second scenario, which would imply that even going for shieldrating far into the DR would reduce the probability of receiving 2 little less large hits in a row i.e. probability of dying. That is exactly the formula we should find out. The lower the probability of suprisingly large hits which put healers under pressure, the better high dtps would be healable and the more healers can anticipate the dmg profile of the tank. Note however that this only occurs at bosses who have a low swing timer.

One thing i noticed at Underlurker HM with my assasin tank was, that when adds spawned and the boss casted his rock smash? on me my hp went under 30%, which puts healers under pressure and might even make them use their cd's. If i'd shield it i would still sit at somewhat around 50%. With more absorb instead of shield i might shield 1 attack less but not fall to 50% with a shielded attack but to 55%. However i still received 1 unpredictable strike more than with prioritizing shield more than absorb which means there is a higher probability of death with more absorb. This theory basically means that in an FT+KE only fight every tank should use shield augments only and get absorb with mods, ear and implas to decrease spikiness.

This however might hurt your dtps, but those are unimportant as long as the tank survives and the healers didnt went totally berserk. But does a healer feel the difference of 100-200 dtps or does he rather "feel" unpredictable and sudden health drops to a dangerous level?

What is the level of hp healers do not panic but see that there is a need for heal? Personally i would say 50% is the treshold where they might feel a little uncomfortable. This treshold should be use to determine absorb. After that the most important thing would be decrease spikiness and not squishiness.This is however my personal view, other players might feel another way.

So to determine it. You have to look into your logs and find the most damaging FT+KE attack. Lets say it was 30k not shielded. 30k would be 54% of your hp pool, meaning you would fall to 46% if your hp is around 55k.So you are underneath the treshold. Now you determine how much you need to be above the treshold. this would be 5%. So basically you would need to get absorb high enough to decrease the attacks dmg by 5% when shielded. This does not mean you would need 5% absorb in total but you would need more because absorb and dmg reduction are multiplicative not additive. This is individually per level of gear and class. If you determined the absorb value you need, the thing left to do is to stack shield as much as possible on the remaining slots. Now mods do not have shield which determines the minimum value of absorb which is mostly already high enough to offer enough absorb to never get underneath that treshold as long as you shield the attack. To further increase that treshold you can also get some more hp. In my theory the more hp you have the less important absorb becomes.

However tanking is not as easy as i sample it here to show you my theory. First of all there are no bosses that only have FT+KE dmg. Even Brontes NM has certain attacks that are MR+KE <tentacles>. Furthermore there are situations where dtps still matter even though the healers are relaxed at first because their tank never get below 50% they still have to heal him like hell. So there again we have to find a mix of reducing probability of death and minimizing dtps.

i suppose if i put up non lettered squish calcs and bmod spike calcs people could figure out where they want to be for inbetween the extremes. but even the numbers i get for minimizing spike seem to be missing the point since the standard deviation doesnt capture what is killing the tanks. the apporach you speak to is very similar in some aspects to kbn's spike approach, which used a half health probability as an exponent, iirc. i feel like the best effort would take heals, tank and boss into account, but at that point all generality is lost.

maybe for each boss a consensus is reached as to what spikes are killing people, and the damage types and frequency of those attacks are taken into account when minimizing damage from those attacks. for example, every time the boss uses ability a then b, by the time c happens, im about to die. most of the time a cooldown can be used here, but one could argue that the gear suggested be based on only damage weights for those attacks.

i still like the idea of the end user deciding, with the aid of healers:

on a scale from 0 to 10, how responsible are sudden spikes of damage responsible for your death? then that factor can be used in optimizing as a balance between squish and spike. the standard deviation approach leave much to be desired. here are graphs for the distributions for commanders and the returned, optimizing for squish and spike.

http://imgur.com/ubmVmgF

it looks like the spike optimization will increase your squish just to even out the probabilities. for the heavy i/e fight, this looks like it would serve the healers well in keeping the damage constant (but the big part that makes damage seem spikey would be the rotation of the boss and phases of the fight more than these probabilities). for the kinetic weapon fight, i dont see a huge benifit in gearing for spike. the distribution is still pretty wild.

ps: putting methoxa and kbn's ideas together gives: 5*dps*(squish+k*spike)<0.5*health. 5* dps can be replaced with a known damage bundle of a fight. squish+k*spike can be replaced with (x*squish+y*spike) or even the maximum squish of the fight (typically i/e damage). 0.5*health can be replaced with whatever health level the healers suggest, or put the damage bundle on the right side of the equation (getting rid of the 5*dps altogether) and have a secondary constraint that health>=damage_bundle, or even health*0.7>=damage_bundle. again, that would be a healer thing to ask. all of these would be things we can optimize endurance and stats to!

using window*dps*(squish+k*spike)>0.5*health, minimizing squish+k*spike , setting k=2, window=5

sin	malphar					jugg	malphar					PT	malphar			
dps	3500	4500	5500	6500		dps	3500	4500	5500	6500		dps	3500	4500	5500	6500
d	1567	1567	582	185		d	2005	2005	356	356		d	1560	1560	1632	1632
s	1200	1200	1887	1928		s	1200	1200	1928	1928		s	1493	1493	1928	1928
a	1236	1236	1372	1728		a	798	798	1557	1557		a	950	950	281	281
base	0.43128	0.43128	0.43703	0.43943		base	0.43968	0.43968	0.45187	0.45187		base	0.45886	0.45886	0.46400	0.46400
D	0.42892	0.42892	0.43357	0.43545		D	0.43758	0.43758	0.44778	0.44778		D	0.45684	0.45684	0.46195	0.46195
A	0.42919	0.42919	0.43449	0.43716		A	0.43778	0.43778	0.44997	0.44997		A	0.45671	0.45671	0.46071	0.46071
S	0.42919	0.42919	0.43482	0.43725		S	0.43795	0.43795	0.45007	0.45007		S	0.45673	0.45673	0.46162	0.46162
relic	WD	WD	WD	WD		relic	WD	WD	WD	WD		relic	WA	#N/A	#N/A	#N/A
=ward	18436	18436	15177	16944		=ward	20209	20209	20306	20306		=ward	18131	18131	16158	16158
spike	0.29622	0.29622	0.28759	0.28481		spike	0.29004	0.29004	0.27479	0.27479		spike	0.30496	0.30496	0.29942	0.29942
b-mods	0	0	9	9		b-mods	0	0	9	9		b-mods	0	0	9	9

0.5*health	26238	26238	27836	27836		0.5*health	25056	25056	26582	26582		0.5*health	25056	25056	26582	26582
pain	17915	23034	27836	32794		pain	17846	22945	27540	32547		pain	18704	24048	29228	34543
buffer	8322	3204	0	-4958		buffer	7210	2111	-958	-5965		buffer	6352	1008	-2646	-7960

sin	Squad					jugg	Squad					PT	Squad			
dps	6500	7500	8500			dps	6500	7500	8500			dps	6500	7500	8500	
d	185	185	185			d	356	356	356			d	185	185	1164	
s	1928	1928	1928			s	1928	1928	1928			s	1200	1200	1928	
a	1890	1890	1728			a	1719	1719	1557			a	2618	2618	853	
base	0.26414	0.26414	0.26860			base	0.26213	0.26213	0.26552			base	0.24271	0.24271	0.24354	
D	0.26033	0.26033	0.26472			D	0.25818	0.25818	0.26152			D	0.23925	0.23925	0.24122	
A	0.25901	0.25901	0.26302			A	0.25823	0.25823	0.26128			A	0.24054	0.24054	0.23753	
S	0.25895	0.25895	0.26324			S	0.25824	0.25824	0.26151			S	0.23788	0.23788	0.23844	
relic	WS	WS	AS			relic	WD	WD	WA			relic	WS	WS	AS	
=ward	7521	7521	7198			=ward	9887	9887	9610			=ward	11173	11173	7564	
spike	0.21099	0.21099	0.20944			spike	0.18761	0.18761	0.18628			spike	0.20330	0.20330	0.18235	
b-mods	0	0	9			b-mods	0	0	9			b-mods	0	0	3.179935731	

0.5*health	26238	26238	27836			0.5*health	25056	25056	26582			0.5*health	25056	25056	25595	
pain	22130	25535	28981			pain	20586	23753	26938			pain	20945	24168	25595	
buffer	4108	703	-1145			buffer	4470	1303	-356			buffer	4110	888	0	

for those who dont want to copy and paste: http://imgur.com/wBDCGtB

something goofy is happening with the triple constraint (between squish, spike and health inequality). id like to max squish unless the spike damage (pain) exceeds half health (buffer).

ps

i am going to call spike sigma from now on. i would liek to use spike to refer to the amount of damage in question (formerly refered to as pain=5*dps*(squish+2*sigma) in these recent tables). also, i dont think i will use the coverage factor approach, only because the x*squish+y*sigma approach can easily be manipulated to give an optimization for squish only, or sigma only. using the minimum of (squish+k*sigma) will make squish 1 part in a million if i set k to 1mil. it is a nuisance in the calcs.

i think i will dive into finding a good trade off point for spike and squish... i am going to need all the dtps numbers (and their average fight time, so i can calc the weighted damage distributions). once i have those i can find a critical sigma maters term for the dps, and a critical damage amount (critical as in special) for a given sigma count, where one would begin to trade in for b mods, given a k factor ( i guess i will use x-factor). note that x=1/(1+k).

to summerize: minimize squish*x+(1-x)*sigma while keeping (health-spike)>buffer

pps: i cant seem to find a way to get squish and sigma on equal footing. the problem is, if squish is more reactive to variable changes than sigma, the optimization will tend to play with squish instead of sigma, and vice versa. i have tried normalizing, but then i get squish and spike in the demoninator for both terms: sigma*x/(sigma+squish) + squish*y/(sigma+squish), where i solve so x/(squish+sigma)=spike_matters/10 and y/(squish+sigma)=(10-spike_matters)/10. this is making the coverage factor k method much more appealing. i am also getting increases in squish for the sake of reducing sigma... it would make healing more predictable, but more energy intensive.

So I wasn't able to replicate your graphs, dipstik. I was playing around with things specifically with shadows and the average profile, and I got the following (note that this is plotting probability over 1-squish, but it's still the same idea): http://imgur.com/2xpoF6T.png

This is defined in a few ways. First, I'm grouping based on squish, rounded to the nearest hundredth. I then compose the probability of being within a particular squish bucket (defined as 1 - product(1-probability)). Data points are treated as {x->s, y->p} and sorted by squish (well, 1-squish). I then interpolate the curves and plot the results. The exact set of data points can be seen here:

{<|p -> 0.211701, s -> 0.281326|>,
<|p -> 0.207476, s -> 0.3|>,
<|p -> 0.31299, s -> 0.695432|>,
<|p -> 0.205507, s -> 1|>}

(remember this is grouped by rounded squish, so there are fewer cases than one might expect)

If I remove the rounding, I get the following dataset:

{<|p->0.211701,s->0.281326|>,
<|p->0.207476,s->0.3|>,
<|p->0.0501468,s->0.695432|>,
<|p->0.27672,s->0.695798|>,
<|p->0.205507,s->1|>}

Which graphs as this: http://imgur.com/Cb4tUhq.png

i would think you would get 6 points. defend/resist, kinetic weapon shielded, kinetic force shielded, kinetic weapon unshielded, kinetic force unshielded and internal.

i like that first curve a lot. that looks like a guassian curve

i would think you would get 6 points. defend/resist, kinetic weapon shielded, kinetic force shielded, kinetic weapon unshielded, kinetic force unshielded and internal.

Kinetic Weapon and Kinetic Force shielded and unshielded are the same values, respectively. Different probabilities, but the same values. Since I'm grouping by squish, those values disappear.

Incidentally, noob question here: should I just be summing these probabilities when I group? I'm pretty sure they're definitionally disjoint.

i like that first curve a lot. that looks like a guassian curve

Mathematica's interpolation gets all the credit there. :-)

Unfortunately, due to grouping and interpolating, my curves are dramatically less interesting than yours. (insert innuendo of choice)

Edit You may find this interesting: http://imgur.com/xTJcfIF.png :-) It's strange, because I would think that this graph would be a lot more useful pivoted to the side, with mitigation up-down and probability left-right. However, that particular data pivot produces an incredibly dense graph full of lots of ups and downs and no clear conclusion. This graph is deceptive, but seems to match the gut test on how each tank feels. Good call on the axes, dipstik.

I have 16 disjoint cases that sum to one, kw_named, kw_bland, kf and ef each coupled with defended, resisted, shielded and full hit.

It looks like you are summing all the probabilities associated with squish=0. The same should should be true for all of like squish.

Also, thanks for the kudos, but you were the first one to graph the probability density graph. Funny, all this time I've been reporting spike, but never thought to graph it.

ps: heres the numbers for all the bosses assuming 6k dps, k=2, using squish to optimize unless 5*dps*(squish (with relic) +k* sigma )>0.5*health, in which case i optimize squish+k*sigma.

sin		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d	185	185	997	605	185	185	823	582	185	1374
s	1928	1908	1574	1676	1928	1901	1558	1922	1908	1928
a	1728	1910	1432	1722	1728	1917	1622	1499	1910	539
base	0.4394	0.2641	0.2234	0.2825	0.4004	0.3471	0.2764	0.3391	0.3463	0.4513
D	0.4354	0.2603	0.2188	0.2780	0.3972	0.3431	0.2720	0.3349	0.3434	0.4497
A	0.4372	0.2591	0.2186	0.2785	0.3970	0.3436	0.2725	0.3354	0.3422	0.4455
S	0.4373	0.2589	0.2188	0.2784	0.3971	0.3435	0.2724	0.3358	0.3421	0.4473
relic	WD	WS	WA	WD	WA	WD	WD	WD	WS	WA
=ward	16944	7621	8402	9545	11593	10616	9759	10296	9298	9556
sigma	0.2848	0.2115	0.2062	0.2446	0.2697	0.2634	0.2461	0.2698	0.2531	0.2576
b-mods	9.0	0.0	0.0	0.0	9.0	0.0	0.0	0.0	0.0	9.0
optimize	1.0051	0.2589	0.2186	0.2780	0.9364	0.3431	0.2720	0.3349	0.3421	0.9608

jugg		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d	356	356	1644	1564	356	1388	1869	356	417	1548
s	1928	1838	1200	1200	1928	1200	1200	1765	1915	1928
a	1557	1809	1159	1239	1557	1322	934	1781	1671	365
base	0.4519	0.2620	0.2262	0.2852	0.4048	0.3510	0.2799	0.3526	0.3457	0.4459
D	0.4478	0.2581	0.2223	0.2819	0.4014	0.3482	0.2768	0.3476	0.3427	0.4443
A	0.4500	0.2584	0.2227	0.2822	0.4021	0.3483	0.2766	0.3501	0.3425	0.4415
S	0.4501	0.2582	0.2226	0.2820	0.4022	0.3480	0.2767	0.3499	0.3425	0.4429
relic	WD	WD	WD	WD	WD	WS	WA	WD	WA	WA
=ward	20306	9963	10704	11897	14298	14030	11998	14648	12054	12918
sigma	0.2748	0.1891	0.2054	0.2426	0.2556	0.2582	0.2451	0.2597	0.2339	0.2456
b-mods	9.0	0.0	0.0	0.0	9.0	5.2	0.0	5.6	0.0	9.0
optimize	0.9974	0.2581	0.2223	0.2819	0.9126	0.3480	0.2766	0.3476	0.3425	0.9326


pt		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d	185	185	920	568	1913	415	953	1304	185	1913
s	1928	1928	1730	1912	1928	1928	1713	1928	1928	1928
a	1728	1890	1353	1523	0	1515	1337	609	1864	0
base	0.4648	0.2318	0.2105	0.2755	0.4194	0.3461	0.2721	0.3495	0.3303	0.4579
D	0.4614	0.2285	0.2065	0.2716	0.4179	0.3429	0.2685	0.3467	0.3277	0.4568
A	0.4629	0.2281	0.2065	0.2720	0.4138	0.3428	0.2686	0.3452	0.3272	0.4525
S	0.4627	0.2274	0.2063	0.2718	0.4156	0.3427	0.2684	0.3461	0.3266	0.4542
relic	WD	WS	WS	WD	WA	WS	WS	WA	WS	WA
=ward	18327	10363	9558	10339	10123	11917	10822	11131	12520	10447
sigma	0.2981	0.1904	0.1794	0.2381	0.2710	0.2690	0.2398	0.2743	0.2583	0.2644
b-mods	9.0	0.0	0.0	0.0	9.0	8.0	0.0	9.0	1.4	9.0
optimize	1.0576	0.2274	0.2063	0.2716	0.9558	0.3427	0.2684	0.8938	0.3266	0.9813

the numbers for 4500 dps:

sin		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d		1567	185	997	605	185	185	823	1142	185	185
s		1200	1908	1574	1676	1901	1901	1558	1496	1908	1908
a		1236	1910	1432	1722	1917	1917	1622	1366	1910	1910
base		0.4313	0.2641	0.2234	0.2825	0.3977	0.3471	0.2764	0.3376	0.3463	0.4328
D		0.4289	0.2603	0.2188	0.2780	0.3945	0.3431	0.2720	0.3343	0.3434	0.4305
A		0.4292	0.2591	0.2186	0.2785	0.3945	0.3436	0.2725	0.3341	0.3422	0.4298
S		0.4292	0.2589	0.2188	0.2784	0.3945	0.3435	0.2724	0.3343	0.3421	0.4297
relic		WD	WS	WA	WD	WD	WD	WD	WA	WS	WS
=ward		18436	7621	8402	9545	12000	10616	9759	11406	9298	12642
sigma		0.2962	0.2115	0.2062	0.2446	0.2720	0.2634	0.2461	0.2753	0.2531	0.2686
b-mods		0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000
optimize		0.4289	0.2589	0.2186	0.2780	0.3945	0.3431	0.2720	0.3341	0.3421	0.4297

jugg		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d		2005	356	1644	1564	1152	1353	1663	1707	421	356
s		1200	1838	1200	1200	1421	1314	1200	1200	1810	1838
a		798	1809	1159	1239	1430	1335	1140	1096	1772	1809
base		0.4397	0.2620	0.2262	0.2852	0.4008	0.3496	0.2799	0.3423	0.3456	0.4350
D		0.4376	0.2581	0.2223	0.2819	0.3984	0.3469	0.2765	0.3394	0.3426	0.4326
A		0.4378	0.2584	0.2227	0.2822	0.3984	0.3469	0.2769	0.3397	0.3426	0.4328
S		0.4379	0.2582	0.2226	0.2820	0.3983	0.3467	0.2767	0.3396	0.3424	0.4327
relic		WD	WD	WD	WD	WS	WS	WD	WD	WS	WD
=ward		20209	9963	10704	11897	15910	13938	12145	14472	12770	16498
sigma		0.2900	0.1891	0.2054	0.2426	0.2626	0.2580	0.2443	0.2711	0.2350	0.2520
b-mods		0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000
optimize		0.4376	0.2581	0.2223	0.2819	0.3983	0.3467	0.2765	0.3394	0.3424	0.4326


pt		Malfar	Squad	Undrlrk	Cmndrs	Retrnd	Sparky 	Bulo 	Torque 	Mstr	Cortani
d		1352	185	920	568	371	470	953	1032	185	185
s		1495	1928	1730	1912	1928	1928	1713	1671	1928	1928
a		1157	1890	1353	1523	1704	1605	1337	1300	1890	1890
base		0.4588	0.2318	0.2105	0.2755	0.4009	0.3437	0.2721	0.3439	0.3299	0.4362
D		0.4567	0.2285	0.2065	0.2716	0.3983	0.3407	0.2685	0.3409	0.3273	0.4342
A		0.4569	0.2281	0.2065	0.2720	0.3983	0.3407	0.2686	0.3410	0.3268	0.4340
S		0.4567	0.2274	0.2063	0.2718	0.3980	0.3404	0.2684	0.3408	0.3263	0.4336
relic		WD	WS	WS	WD	WS	WS	WS	WS	WS	WS
=ward		18350	10363	9558	10339	14909	12523	10822	12835	12688	17149
sigma		0.3050	0.1904	0.1794	0.2381	0.2849	0.2707	0.2398	0.2793	0.2587	0.2849
b-mods		0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000	0.0000
optimize		0.4567	0.2274	0.2063	0.2716	0.3980	0.3404	0.2684	0.3408	0.3263	0.4336

Here is the full set of mitigation cases, plotted over all mitigation profiles: http://imgur.com/jGlkh92.png

I think I actually have a pretty good intuition for why this graph represents spikiness now. Notice how Vanguards (and to a lesser extent Guardians) basically "sit' in the higher probabilities. Their mitigation may not be quite as good overall, but their cases are all in nearly the same "probability stratum", and that stratum is quite elevated. Thus, Vanguards will, with roughly equal probability, mitigate varying percentages of hits. Because it is roughly equal probability, a healer (or anyone else looking at the health bar over time) is just going to "get used" to seeing the fluctuations in mitigation. Nothing unusual happens, because nothing is unusual! Since everything is nearly the same probability, nothing is out of the ordinary.

Shadows are the opposite. They have some really awesome mitigation cases, and it's easy to see looking at the graph how their mitigation can average out to be higher than a Vanguard. However, their probabilities are all over the map. There are some low probability cases which look very different from the high probability cases. Contrary to what the intuitive reading might imply, the two points in the center are not a good example of this (since the casual observer wouldn't ever see a difference between these points). A better example is the cluster pair of points on the far left compared to the apex of the curve in the middle. The apex is high probability and quite good mitigation. Off to the right is almost as much of a contrast, with consistently one of the highest probability max-mitigation cases (Guardians are nearly even, but slightly ahead).

Anyway, this is basically the same intuition that we can derive for why shadows have the lowest standard deviation. In both cases, the "sharpness" of the graph is more interesting than the precise magnitudes, and I think that both graphs (but especially the cases one) do a pretty good job of reflecting player intuition on how the tanks feel.

i agree. i think the spikiness of a tank pertains to the probability variance, and psychology thereof, more than the squish variance.

gearing to reduce sigma does serve to reduce the variance in probabilities it seems. this should give healers a better health flux of the tank to respond to, even though they are taking more damage.