Theck's MATLAB thread - Cataclysm/4.x
Moderators: Fridmarr, Worldie, Aergis, theckhd
Re: Theck's MATLAB thread - Cataclysm/4.x
I think I have the FSM implementation working now. Here's a sample output of the updated single-target queue comparisons. Keep in mind that this is still preliminary. I'm 99% sure the code is working properly, but I haven't had the time to evaluate it as thoroughly as usual.
Note the FSM code uses a new notation. An "I-" prefix means "iff Inq active," while an "i-" prefix means "iff Inq not active." "SD-" and "sd-" have similar connotations. AS+ still means "AS iff GC buff active."
The main reason I'm posting this is for people to look at the numbers and do some sanity checking - make sure there's nothing on here that seems nonsensical, like a queue that should have Inq uptime but doesn't, etc.
Note the FSM code uses a new notation. An "I-" prefix means "iff Inq active," while an "i-" prefix means "iff Inq not active." "SD-" and "sd-" have similar connotations. AS+ still means "AS iff GC buff active."
The main reason I'm posting this is for people to look at the numbers and do some sanity checking - make sure there's nothing on here that seems nonsensical, like a queue that should have Inq uptime but doesn't, etc.
- Code: Select all
SoT / 2% hit / 16 exp
DPS TPS SHPS E I
Q# Priority V=100% V=30% V=100% V=30% V=100% V=30% % %
1 SotR>CS>AS>J 14375 9249 43126 27747 0 0 7.3 0.0
2 SotR>HotR>AS>J 13085 8323 39256 24970 0 0 7.3 0.0
3 SotR>CS>J>AS 14271 9169 42813 27506 0 0 7.4 0.0
4 SotR>AS>CS>J 14198 9135 42595 27405 0 0 8.6 0.0
5 AS>SotR>CS>J 14067 9052 42202 27155 0 0 9.2 0.0
6 SotR>CS>AS+>J>AS 14346 9224 43039 27672 0 0 7.3 0.0
7 SotR>AS+>CS>J>AS 14320 9207 42959 27621 0 0 7.7 0.0
8 sdAS>sdJ>SotR>CS>AS>J 13831 8888 41493 26663 0 0 11.6 0.0
9 sdAS>SotR>CS>AS>J 14229 9155 42686 27465 0 0 8.8 0.0
10 SotR>CS>AS>J>HW 14611 9485 43834 28455 0 0 2.8 0.0
11 SotR>CS>AS>J>Cons>HW 14806 9590 44418 28770 0 0 1.6 0.0
12 SotR>AS+>CS>AS>J>Cons>HW 14781 9576 44345 28728 0 0 1.8 0.0
13 sdAS>sdJ>SotR>AS+>CS>AS>J>Cons>HW 14331 9291 42994 27873 0 0 4.8 0.0
14 Inq>CS>AS>J 12625 8114 37874 24342 0 0 7.7 89.0
15 Inq>HotR>AS>J 11961 7570 35882 22710 0 0 7.7 89.0
16 iInq>SotR>CS>AS>J 13955 8972 41866 26917 0 0 7.6 63.2
17 ISotR>Inq>CS>AS>J 13955 8972 41866 26917 0 0 7.6 63.2
18 SDSotR>ISotR>Inq>CS>AS>J 14452 9294 43356 27881 0 0 7.5 41.5
19 ISotR>SDSotR>Inq>CS>AS>J 14452 9294 43356 27881 0 0 7.5 41.5
20 ISDSotR>Inq>CS>AS>J 13794 8867 41382 26602 0 0 7.6 73.5
21 Inq>CS>AS>J>Cons>HW 13193 8566 39581 25699 0 0 1.8 89.0
22 Inq>HotR>AS>J>Cons>HW 12530 8022 37590 24066 0 0 1.8 89.0
23 ISotR>Inq>CS>AS>J>Cons>HW 14461 9373 43383 28119 0 0 1.7 63.2
24 SDSotR>ISotR>Inq>CS>AS>J>Cons>HW 14935 9677 44806 29030 0 0 1.7 41.5
25 SDSotR>ISotR>Inq>CS>AS>J>ICons>HW 14874 9644 44624 28933 0 0 2.1 41.5
26 SDSotR>Inq>CS>AS>J>Cons>HW 14783 9581 44351 28745 0 0 1.7 51.2
27 ISDSotR>Inq>CS>AS>J>Cons>HW 14324 9288 42973 27865 0 0 1.7 73.5
28 WoG>SotR>CS>AS>J>Cons>HW 13618 8828 40854 26485 1266 902 1.7 0.0
29 WoG>SotR>HotR>AS>J>Cons>HW 12307 7887 36922 23663 1266 902 1.7 0.0
30 WoG>Inq>CS>AS>J>Cons>HW 12671 8226 38013 24680 1269 904 1.8 58.9
31 WoG>Inq>HotR>AS>J>Cons>HW 11795 7551 35385 22654 1269 904 1.8 58.9
32 WoG>Inq>AS+>CS>AS>J>Cons>HW 12680 8236 38042 24708 1251 892 2.1 58.1
33 WoG>ISotR>Inq>CS>AS>J>Cons>HW 13246 8593 39740 25781 1267 903 1.7 44.0
34 WoG>iInq>SotR>CS>AS>J>Cons>HW 13246 8593 39740 25781 1267 903 1.7 44.0
35 SotR>CS>AS>J>HoW 15569 10072 46706 30217 0 0 1.6 0.0
36 SotR>CS>AS>HoW>J 15906 10338 47718 31015 0 0 0.3 0.0
37 SotR>CS>HoW>AS>J 15864 10337 47592 31011 0 0 0.3 0.0
38 SotR>HoW>CS>AS>J 15722 10261 47165 30783 0 0 1.3 0.0
39 HoW>SotR>CS>AS>J 15608 10197 46823 30591 0 0 1.9 0.0
40 SotR>CS>AS+>HoW>AS>J 15907 10349 47722 31047 0 0 0.2 0.0
41 SotR>CS>HoW>AS>J>Cons>HW 15896 10358 47689 31075 0 0 0.0 0.0
42 SotR>HoW>CS>AS>J>Cons>HW 15851 10349 47554 31048 0 0 0.0 0.0
43 HoW>SotR>CS>AS>J>Cons>HW 15790 10325 47370 30975 0 0 0.0 0.0
44 ISotR>Inq>CS>HoW>AS>J>Cons>HW 15856 10357 47567 31071 0 0 0.0 62.3
45 HoW>ISotR>Inq>CS>AS>J>Cons>HW 15912 10439 47738 31317 0 0 0.0 63.3
46 WoG>HoW>SotR>CS>AS>J>Cons>HW 14669 9601 44007 28802 1272 906 0.0 0.0
47 WoG>SotR>HoW>CS>AS>J>Cons>HW 14764 9653 44294 28960 1225 873 0.0 0.0
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Theck's MATLAB thread - Cataclysm/4.x
Edit: I read the text on SD incorrectly, I assumed you would only get a SD proc if the AS was a GC proc'ed one.
Probably not very important, but rotation #13 should probably be changed to:
sdAS+>sdJ>SotR>AS+>CS>AS>J>Cons>HW
I'm assuming that its supposed to be a SD fishing rotation, proving that we shouldn't fish for procs, but atm you currently have it casting AS regardless of GC status meaning its casting ASs without the chance to gain SD.
On a side note yay for my rotation looking like its doing the best atm (epeen++)
Probably not very important, but rotation #13 should probably be changed to:
sdAS+>sdJ>SotR>AS+>CS>AS>J>Cons>HW
I'm assuming that its supposed to be a SD fishing rotation, proving that we shouldn't fish for procs, but atm you currently have it casting AS regardless of GC status meaning its casting ASs without the chance to gain SD.
On a side note yay for my rotation looking like its doing the best atm (epeen++)
- daiceman
- Posts: 43
- Joined: Tue Apr 22, 2008 1:53 pm
Re: Theck's MATLAB thread - Cataclysm/4.x
daiceman wrote:I'm assuming that its supposed to be a SD fishing rotation, proving that we shouldn't fish for procs, but atm you currently have it casting AS regardless of GC status meaning its casting ASs without the chance to gain SD.
The wording of PTR Sacred Duty doesn't indicate that you need a GrCr proc for AS to proc SD. Unless I'm missing something, you can still fish for an SD proc even if you're not going to get any HP from it.
- Iminmmnni
- Posts: 46
- Joined: Thu Mar 24, 2011 4:41 pm
- Location: Melbourne
Re: Theck's MATLAB thread - Cataclysm/4.x
Single-target rotation simulations are updated. I probably won't get to the rest of them until this afternoon/evening.
Interestingly, there's a slight DPS gain to be had over the default 939. (SotR if SD or Inq active)>Inq>CS>AS>J beats out SotR>CS>AS>J by a hair (~75-100 DPS). Still less than a 1% increase though, so it's not clear if that's worth the extra mental bandwidth. On the other hand, if you're using a rotation manager like clcinfo, it should be easy enough to code the conditionals.
Interestingly, there's a slight DPS gain to be had over the default 939. (SotR if SD or Inq active)>Inq>CS>AS>J beats out SotR>CS>AS>J by a hair (~75-100 DPS). Still less than a 1% increase though, so it's not clear if that's worth the extra mental bandwidth. On the other hand, if you're using a rotation manager like clcinfo, it should be easy enough to code the conditionals.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Theck's MATLAB thread - Cataclysm/4.x
Thnx once more Theck. I can prepare for wednesdays raid
.
I like the spec from the sim, I will prolly use it. Also replacing wog glyph with CS.
Finally we are allowed to care abit more about dps
.
I like the spec from the sim, I will prolly use it. Also replacing wog glyph with CS.
Finally we are allowed to care abit more about dps
-

Awyndel - Posts: 672
- Joined: Sat Feb 14, 2009 8:49 am
- Location: The Netherlands
Re:
I have no idea how feasible this is with your Sim coding, but wouldn't a cooldown based check work better for this? As in use a SotR if you have 3 Holy Power (Unlikely but can potentially happen if WoG>CS>AS+>CS ends up happening) or if a certain amount of time/ability uses is left until WoG is ready again. Time variations would likely be in the 9.5-15.5 seconds range depending on how save you want to play it: 15.5 seconds usually leading to an effective "use SotR2 once" in most cycles if I'm looking at things correctly, whereas the 9.5 seconds end of the range would result in trading more HPS for DPS; varying with your expertise/hit obviously.theckhd wrote:
- It's very likely that WoG>SotR2>CS>AS>J is a slight DPS boost over WoG>CS>AS>J for little to no SHPS cost. This will be added to the sims in the next pass.
To summarize: Is it a good idea to burn your currently available Holy Power on a SotR when there's a certain amount of time left before WoG is ready again?

-

Chicken - Posts: 1597
- Joined: Fri Jun 26, 2009 2:19 pm
Re: Re:
Chicken wrote:I have no idea how feasible this is with your Sim coding, but wouldn't a cooldown based check work better for this? As in use a SotR if you have 3 Holy Power (Unlikely but can potentially happen if WoG>CS>AS+>CS ends up happening) or if a certain amount of time/ability uses is left until WoG is ready again. Time variations would likely be in the 9.5-15.5 seconds range depending on how save you want to play it: 15.5 seconds usually leading to an effective "use SotR2 once" in most cycles if I'm looking at things correctly, whereas the 9.5 seconds end of the range would result in trading more HPS for DPS; varying with your expertise/hit obviously.theckhd wrote:
- It's very likely that WoG>SotR2>CS>AS>J is a slight DPS boost over WoG>CS>AS>J for little to no SHPS cost. This will be added to the sims in the next pass.
To summarize: Is it a good idea to burn your currently available Holy Power on a SotR when there's a certain amount of time left before WoG is ready again?
Yes, it's entirely feasible for the FSM code to handle that, we just have to define a parameter for it. A generic parameter for checking the cooldown of another spell is probably the best way to implement it - i.e. "SotR(cdWoG>3)" or something.
Side note: all of the sims on the front page are updated to r290. I'll probably do another pass in a day or two with any bugfixes and such.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Re:
theckhd wrote:Yes, it's entirely feasible for the FSM code to handle that, we just have to define a parameter for it. A generic parameter for checking the cooldown of another spell is probably the best way to implement it - i.e. "SotR(cdWoG>3)" or something.
fsm code has been updated to handle conditionals of the form [cd|buff<Ability/Buff><op><value>]
. We can now run rotations such as WoG>SotR[cdWoG>15]>CS>AS>J. I put the logic in for both cooldowns and buffs so we can do stuff like Inq[buffInq<3] as well. iInq/ISotR et al (and the sd/SD variants) are now just shorthands for Inq[buffInq=0]/SotR[buffInq>0]. (The rotation parsing code is much more complicated now as > is now being used as both the separator for the abilities CS>AS and a conditional operator).
Aside: the code is now using an analytical model instead of simulations. It's *significantly* more computationally expensive than the previous model but a whole lot faster than running simulations. As we're no longer performing simulations, 50dps between rotations is actually meaningful again.
- Iminmmnni
- Posts: 46
- Joined: Thu Mar 24, 2011 4:41 pm
- Location: Melbourne
Re: Theck's MATLAB thread - Cataclysm/4.x
Depends on how you define 'meaningful'. The analysis might be perfectly accurate, but it model is too ideal to be real world accurate to that degree. .3% changes in DPS tend to smooth out once mental bandwith, game lag, movement, miss streaks, using Hand spells on raid members, etc happen.
- raistlin212
- Posts: 12
- Joined: Tue Oct 19, 2010 6:11 am
Re:
theckhd wrote:Single-Target Rotation Simulations
The simulation has extremely tight error tolerances, giving us accuracy down to ~1 DPS. So any difference in the output of two queues can be considered statistically significant from a purely mathematical point of view. However, keep in mind that the results are only as good as the model, and the model is Patchwerk with no latency. So talking about differences smaller than 10-25 DPS is probably still meaningless, even if our numerical accuracy is better than that.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Theck's MATLAB thread - Cataclysm/4.x
Yeah, what he said (twice).
- raistlin212
- Posts: 12
- Joined: Tue Oct 19, 2010 6:11 am
Re: Theck's MATLAB thread - Cataclysm/4.x
Weapon Calculation updated again to include the new ZG/ZA weapons. Renataki's is a very nice addition, essentially replacing Soul Blade as the pre-raid tanking weapon of choice.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Theck's MATLAB thread - Cataclysm/4.x
I have updated results for the single-target rotation sims, but rather than updating the first post 3 or 4 times, let's spend a little time discussing which queues should be added/removed.
Note that simulation time is basically irrelevant now, as the whole thing takes under a minute, so in theory we could just add any queue we want. The counter-argument is that from an aesthetic point of view, the list is far easier to read if we trim it down to only the queues that we care about.
The counter-counter-argument is that sifting through the raw data and distilling it into a concise commentary section is my job, and that people not interested in the raw data probably skip the table and just read the bullet points I type up anyway, so I should just dump all the raw data in the table for completeness.
Anyhow, here's the raw data for 939/SoT/2%/10:
For further commentary on 29-34:
-29 doesn't cast SotR at all, and has a mean time between WoGs (MTBW) of 21.0 seconds
-30 has a MTBW of 25.5s and a mean time between successful SotRs (MTBSS) of 17.1 seconds.
-31 has a MTBW of 21.3s and a MTBSS of 39.3s.
-32 has a MTBW of 21.3s and a MTBSS of 24.2s (all SotR2).
-33 has a MTBW of 22.4s and a MTBSS of 15.0s (all SotR2).
-34 has a MTBW of 21.3s and a MTBSS of 24.2s (all SotR2).
It seems obvious to me now that 33 & 34 don't do what I wanted them to - the conditionals should really be SotR2[10>cdWoG>5] and SotR2[15>cdWoG>10] respectively, but the FSM won't parse those as inputs. I haven't had a chance to look at the conditional parsing code yet to see if there's a way to handle a double conditional (cdWoG>5 && cdWoG<10). That said, I'm not sure it's entirely necessary to pursue those options - most of what we want to know can be inferred from 30-32.
30 delays WoG by ~4.5 seconds (compared to 29) to fit in a 3 HP SotR, trading about 270 HPS for 2.5k DPS.
31 delays WoG by a negligible amount, but only manages to fire off about 43% of the SotRs that 30 does. It recovers almost all of the HPS of 29 but beats it in DPS by about 700.
32 is more or less identical to 31 in terms of HPS, but at a significant DPS loss. It's only 200 DPS ahead of 29 for a minimal HPS cost. The poor scaling of SotR2 is probably what makes this a terrible option - even with more frequent SD utilization, you're hitting for far less thanks to the nonlinear scaling of SotR.
My expectation for 33/34 (if I had coded them with the right conditionals, anyhow) was to fall somewhere between 30 and 31. In essence, you'd get 3-point SotRs off whenever you could, but if it looked grim you'd settle for a 2-pointer before starting your next WoG build-up. It's probably safe to say that the DPS increase from this would be very small though, and perhaps more importantly would be more difficult to execute.
In any event, I'm open to suggestions about what queues should be added/removed/etc. For the sims on the first page, I've been using "WoG>SotR>AS>J>Cons>HW" as the default for W39.
Note that simulation time is basically irrelevant now, as the whole thing takes under a minute, so in theory we could just add any queue we want. The counter-argument is that from an aesthetic point of view, the list is far easier to read if we trim it down to only the queues that we care about.
The counter-counter-argument is that sifting through the raw data and distilling it into a concise commentary section is my job, and that people not interested in the raw data probably skip the table and just read the bullet points I type up anyway, so I should just dump all the raw data in the table for completeness.
Anyhow, here's the raw data for 939/SoT/2%/10:
- Code: Select all
DPS TPS SHPS E I
Q# Priority V=100% V=30% V=100% V=30% V=100% V=30% % %
1 SotR>CS>AS>J 14242 9173 42727 27520 0 0 7.3 0.0
2 SotR>HotR>AS>J 13125 8360 39374 25079 0 0 7.3 0.0
3 SotR>CS>J>AS 14135 9091 42405 27273 0 0 7.4 0.0
4 SotR>AS>CS>J 14077 9067 42231 27201 0 0 8.6 0.0
5 AS>SotR>CS>J 13947 8985 41842 26954 0 0 9.2 0.0
6 SotR>CS>AS+>J>AS 14211 9147 42633 27441 0 0 7.3 0.0
7 SotR>AS+>CS>J>AS 14190 9134 42570 27401 0 0 7.7 0.0
8 sdAS>sdJ>SotR>CS>AS>J 13726 8830 41178 26490 0 0 11.6 0.0
9 sdAS>SotR>CS>AS>J 14107 9087 42322 27261 0 0 8.8 0.0
10 SotR>CS>AS>J>HW 14479 9410 43437 28230 0 0 2.8 0.0
11 SotR>CS>AS>J>Cons>HW 14673 9515 44021 28546 0 0 1.6 0.0
12 SotR>AS+>CS>AS>J>Cons>HW 14655 9505 43964 28515 0 0 1.8 0.0
13 sdAS>sdJ>SotR>CS>AS>J>Cons>HW 14227 9234 42681 27703 0 0 4.8 0.0
14 Inq>CS>AS>J 12518 8053 37553 24160 0 0 7.7 94.1
15 Inq>HotR>AS>J 12034 7627 36101 22880 0 0 7.7 94.1
16 iInq>SotR>CS>AS>J 13870 8926 41611 26777 0 0 7.6 72.3
17 iInq>SotR2>CS>AS>J 12676 8163 38029 24488 0 0 5.2 0.0
18 ISotR>Inq>CS>AS>J 13870 8926 41611 26777 0 0 7.6 72.3
19 SDSotR>ISotR>Inq>CS>AS>J 14351 9237 43052 27712 0 0 7.5 47.5
20 ISotR>SDSotR>Inq>CS>AS>J 14351 9237 43052 27712 0 0 7.5 47.5
21 ISDSotR>Inq>CS>AS>J 13701 8816 41102 26447 0 0 7.6 81.0
22 Inq>CS>AS>J>Cons>HW 13088 8506 39264 25520 0 0 1.8 94.1
23 Inq>HotR>AS>J>Cons>HW 12604 8079 37812 24240 0 0 1.8 94.1
24 ISotR>Inq>CS>AS>J>Cons>HW 14376 9327 43130 27982 0 0 1.7 72.3
25 SDSotR>ISotR>Inq>CS>AS>J>Cons>HW 14834 9621 44504 28865 0 0 1.7 47.5
26 SDSotR>ISotR>Inq>CS>AS>J>ICons>HW 14774 9589 44322 28767 0 0 2.1 47.5
27 SDSotR>Inq>CS>AS>J>Cons>HW 14679 9524 44038 28572 0 0 1.7 56.4
28 ISDSotR>Inq>CS>AS>J>Cons>HW 14232 9237 42696 27713 0 0 1.7 81.0
29 WoG>CS>AS>J 11522 7425 34566 22275 1537 1096 10.5 0.0
30 WoG>SotR>CS>AS>J 13046 8404 39137 25212 1268 904 7.5 0.0
31 WoG>SotR[cdWoG>10]>CS>AS>J 12220 7874 36660 23623 1519 1083 9.0 0.0
32 WoG>SotR2[cdWoG>10]>CS>AS>J 11729 7556 35187 22669 1518 1082 8.7 0.0
33 WoG>SotR[cdWoG>10]>SotR2[cdWoG>5]>CS>AS>J 11921 7678 35764 23035 1441 1028 7.2 0.0
34 WoG>SotR[cdWoG>15]>SotR2[cdWoG>10]>CS>AS>J 11729 7556 35187 22669 1518 1082 8.7 0.0
35 WoG>Inq>CS>AS>J 12041 7749 36124 23248 1270 906 7.7 65.1
36 WoG>CS>AS>J>Cons>HW 12026 7834 36080 23502 1537 1096 3.6 0.0
37 WoG>SotR>CS>AS>J>Cons>HW 13482 8750 40446 26252 1268 904 1.7 0.0
38 WoG>SotR2>CS>AS>J>Cons>HW 13041 8444 39123 25332 0 0 0.6 0.0
39 WoG>Inq>CS>AS>J>Cons>HW 12567 8167 37702 24503 1270 906 1.8 65.1
40 WoG>Inq>HotR>AS>J>Cons>HW 11871 7609 35613 22828 1270 906 1.8 65.1
41 WoG>Inq>AS+>CS>AS>J>Cons>HW 12582 8181 37748 24543 1253 893 2.1 64.2
42 WoG>ISotR>Inq>CS>AS>J>Cons>HW 13144 8535 39432 25607 1269 905 1.7 50.3
43 WoG>iInq>SotR>CS>AS>J>Cons>HW 13144 8535 39432 25607 1269 905 1.7 50.3
44 SotR>CS>AS>J>HoW 15437 9998 46310 29995 0 0 1.6 0.0
45 SotR>CS>AS>HoW>J 15774 10264 47323 30793 0 0 0.3 0.0
46 SotR>CS>HoW>AS>J 15729 10261 47186 30782 0 0 0.3 0.0
47 SotR>HoW>CS>AS>J 15597 10192 46791 30575 0 0 1.3 0.0
48 HoW>SotR>CS>AS>J 15493 10134 46478 30402 0 0 1.9 0.0
49 SotR>CS>AS+>HoW>AS>J 15773 10273 47318 30820 0 0 0.2 0.0
50 SotR>CS>AS>J>HoW>Cons>HW 15585 10102 46756 30307 0 0 0.0 0.0
51 SotR>CS>AS>HoW>J>Cons>HW 15806 10285 47418 30855 0 0 0.0 0.0
52 SotR>CS>HoW>AS>J>Cons>HW 15761 10282 47283 30846 0 0 0.0 0.0
53 SotR>HoW>CS>AS>J>Cons>HW 15727 10280 47181 30841 0 0 0.0 0.0
54 HoW>SotR>CS>AS>J>Cons>HW 15675 10262 47026 30786 0 0 0.0 0.0
55 ISotR>SDSotR>Inq>CS>AS>J>HoW>Cons>HW 15869 10288 47609 30865 0 0 0.0 47.5
56 ISotR>SDSotR>Inq>CS>AS>HoW>J>Cons>HW 16144 10513 48432 31539 0 0 0.0 49.7
57 ISotR>SDSotR>Inq>CS>HoW>AS>J>Cons>HW 16109 10522 48326 31565 0 0 0.0 50.3
58 ISotR>SDSotR>Inq>HoW>CS>AS>J>Cons>HW 16161 10580 48484 31741 0 0 0.0 48.8
59 ISotR>SDSotR>HoW>Inq>CS>AS>J>Cons>HW 16138 10569 48414 31707 0 0 0.0 48.0
60 HoW>ISotR>SDSotR>Inq>CS>AS>J>Cons>HW 16111 10565 48333 31695 0 0 0.0 51.8
61 WoG>SotR>CS>AS>J>HoW>Cons>HW 14415 9351 43245 28054 1268 904 0.0 0.0
62 WoG>SotR>CS>AS>HoW>J>Cons>HW 14675 9560 44027 28679 1268 904 0.0 0.0
63 WoG>SotR>CS>HoW>AS>J>Cons>HW 14656 9574 43969 28721 1257 896 0.0 0.0
64 WoG>SotR>HoW>CS>AS>J>Cons>HW 14636 9581 43909 28742 1227 875 0.0 0.0
65 WoG>HoW>SotR>CS>AS>J>Cons>HW 14546 9532 43639 28596 1273 908 0.0 0.0
For further commentary on 29-34:
-29 doesn't cast SotR at all, and has a mean time between WoGs (MTBW) of 21.0 seconds
-30 has a MTBW of 25.5s and a mean time between successful SotRs (MTBSS) of 17.1 seconds.
-31 has a MTBW of 21.3s and a MTBSS of 39.3s.
-32 has a MTBW of 21.3s and a MTBSS of 24.2s (all SotR2).
-33 has a MTBW of 22.4s and a MTBSS of 15.0s (all SotR2).
-34 has a MTBW of 21.3s and a MTBSS of 24.2s (all SotR2).
It seems obvious to me now that 33 & 34 don't do what I wanted them to - the conditionals should really be SotR2[10>cdWoG>5] and SotR2[15>cdWoG>10] respectively, but the FSM won't parse those as inputs. I haven't had a chance to look at the conditional parsing code yet to see if there's a way to handle a double conditional (cdWoG>5 && cdWoG<10). That said, I'm not sure it's entirely necessary to pursue those options - most of what we want to know can be inferred from 30-32.
30 delays WoG by ~4.5 seconds (compared to 29) to fit in a 3 HP SotR, trading about 270 HPS for 2.5k DPS.
31 delays WoG by a negligible amount, but only manages to fire off about 43% of the SotRs that 30 does. It recovers almost all of the HPS of 29 but beats it in DPS by about 700.
32 is more or less identical to 31 in terms of HPS, but at a significant DPS loss. It's only 200 DPS ahead of 29 for a minimal HPS cost. The poor scaling of SotR2 is probably what makes this a terrible option - even with more frequent SD utilization, you're hitting for far less thanks to the nonlinear scaling of SotR.
My expectation for 33/34 (if I had coded them with the right conditionals, anyhow) was to fall somewhere between 30 and 31. In essence, you'd get 3-point SotRs off whenever you could, but if it looked grim you'd settle for a 2-pointer before starting your next WoG build-up. It's probably safe to say that the DPS increase from this would be very small though, and perhaps more importantly would be more difficult to execute.
In any event, I'm open to suggestions about what queues should be added/removed/etc. For the sims on the first page, I've been using "WoG>SotR>AS>J>Cons>HW" as the default for W39.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
MATLAB 5.x, Call to Arms 5.x, Talent Spec & Glyph Guide 5.x, Blog: Sacred Duty
-

theckhd - Moderator
- Posts: 7467
- Joined: Thu Jul 31, 2008 3:06 pm
- Location: Harrisburg, PA
Re: Theck's MATLAB thread - Cataclysm/4.x
Suggestion 1:
Only host a show of the best queues in the post here, provide a link to a fully detailed summary on a website elsewhere; optimally allow results on said website to be filtered or sorted in various ways. That means all the informations stays available for those interested, but the list of specs to check through for someone wanting quick optimal results isn't as big as it is now.
Suggestion 2:
Split up the "optimal queue" process. First do a bunch of cases with just SotR as finisher, which tests out which is the optimal filler queue to use. Once you've established the optimal filler queue, start examining the various different finisher queues. I think this would cut out a reasonable amount of queues, and as far as I can see browsing through the current large list, the optimal filler isn't dependent on the finishers used.
Only host a show of the best queues in the post here, provide a link to a fully detailed summary on a website elsewhere; optimally allow results on said website to be filtered or sorted in various ways. That means all the informations stays available for those interested, but the list of specs to check through for someone wanting quick optimal results isn't as big as it is now.
Suggestion 2:
Split up the "optimal queue" process. First do a bunch of cases with just SotR as finisher, which tests out which is the optimal filler queue to use. Once you've established the optimal filler queue, start examining the various different finisher queues. I think this would cut out a reasonable amount of queues, and as far as I can see browsing through the current large list, the optimal filler isn't dependent on the finishers used.

-

Chicken - Posts: 1597
- Joined: Fri Jun 26, 2009 2:19 pm
Re: Theck's MATLAB thread - Cataclysm/4.x
My suggestion:
* List the "practical" queues that make the most sense to stick to. For me, this means a non-Hammer of Wrath, and a Hammer of Wrath queue (for when it becomes usable)
* Provide information, *relative* to the optimal queues as a simple TPS loss value. It would describe how much of a threat loss it is to use SoI and/or WoG instead of SoT and ShoR. This way people can easily know "40k optimal, with SoI I'd lose 8k, cool I can expect about 32k, or whatever). They don't need to see rotations with WoG and SoI in it. They just need to know what kind of loss they can expect.
* Provide an scenario or two that talk about the rotations that are practical, and which might provide a bit more TPS when executed perfectly. But don't recommend them when we're talking 20 extra TPS!
In other words, people want a summary with some tips. I don't think most of us want a list of even 10 rotations. I want the one best rotation, and some sense of how it relates to other options.
* List the "practical" queues that make the most sense to stick to. For me, this means a non-Hammer of Wrath, and a Hammer of Wrath queue (for when it becomes usable)
* Provide information, *relative* to the optimal queues as a simple TPS loss value. It would describe how much of a threat loss it is to use SoI and/or WoG instead of SoT and ShoR. This way people can easily know "40k optimal, with SoI I'd lose 8k, cool I can expect about 32k, or whatever). They don't need to see rotations with WoG and SoI in it. They just need to know what kind of loss they can expect.
* Provide an scenario or two that talk about the rotations that are practical, and which might provide a bit more TPS when executed perfectly. But don't recommend them when we're talking 20 extra TPS!
In other words, people want a summary with some tips. I don't think most of us want a list of even 10 rotations. I want the one best rotation, and some sense of how it relates to other options.
- inthedrops
- Maintankadonor
- Posts: 1281
- Joined: Mon Oct 29, 2007 9:19 am
Return to Advanced Theorycraft and Calculations
Who is online
Users browsing this forum: Google [Bot] and 2 guests
