The 'too small sample size' argument doesn't work here, and I'm getting a bit sick of hearing it.

Here we make the assumption that each identical spell takes the same amount of time to cast, with everything else held constant. This doesn't include lag, its just the assumption that the formula which DAOC uses to calculate the cast time of a spell has no randomness attributed to it. (this is of course contrary to how weapon damage works, which varies with each hit).

If you stack 12 equally sized boxes on top of each other and find that their total height is 1 foot, then each box has a height of 1 inch! This is NOT STATISTICS, its DIVISION! If you stack 48 of those boxes on top of each other and measure the total height to be 4 feet, then each box is still 1 inch.

If you want to talk about a meaningful sample size, then here is how you do it. Cast 100 spells, make note of the total time and divide by 100, write down what you get, call it the cast time. This is one sample. Now, repeat this test 29 more times and record what you get each time. Now you have a sample size of 30, and you could analyze things like the standard deviation, a measure of how far each individual cast time is from the overall mean of the 30 slightly differing cast times. But this experiment wouldn't be carried out to test the cast time, it would be to test the ability of the experimenter in accurately recording down the cast time (like we don't know how to use a stopwatch), or tests for the accuracy of the exact same experiment taking place at different times or on different computers/connections (not the spell cast of one spell, but of 100).

When we are doing things like calculating damage variance of an unstyled weapon swing, then we better do so with a large sample size. Each sample corresponds to one weapon swing, we don't need to swing a weapon 100 times and then take the average, because our handy combat log tells us exactly how much damage we hit for (rounded to an integer). If our combat log told us the duration of each spell cast right after we casted it, then there wouldn't be much to discuss in this thread.

But there are a few reasons why we don't need to worry about the above experiment for 100 spell casts.
1) Its actually a pretty obvious assumption to make that lag shouldn't have much effect on chain casting 100 spells. What is the spell followup function meant for anyways? Would we be crazy to assume that when you cast a followup spell, your clients sends a message to the server (in less time than it takes to cast a spell) telling it to immediately start casting the next spell, and therefore eliminating the effects of server lag when chain casting? We would assume lag can only have a noticeable impact on the first or last spell, and therefore certainly it wouldn't throw off the numbers by more than a second, and if you include a 1 second error for someone manually calculating the total time for 100 casts, then you're still around 2% or less error, which for the purposes of this experiment is very accurate.

2) The experiment testing for differences in connection/computer for an identical spell cast test has essentially already been carried out by slajzer and many
other people, who have repeated the same experiment with very close numbers. So we can say with fairly high confidence that doing the same experiment of 100 spell casts will give the same numbers on different computers/connections.

3) Even if you get fairly differing numbers of the exact same 100 spell casts from different computers/connections or at different times, this STILL would not matter, because the entire purpose of everything Slajzer has done is NOT to calculate cast times, but rather to determine 'breaking points' where one more point of dexterity gives you significantly faster cast times. These breaking points have been verified many times by many other people. If you get a 15% decrease in casting time from one more point of dex at a breaking point, then you only have to make sure that the 15% is not accounted for in your error of say a maximum of 1 second for lag and 1 second for the guy on the stopwatch. And again this should never be more than about 2% when you are casting a spell 100 times. So 100 casts is plenty enough, just as 48 boxes is sufficient to estimate the height of each box to 99% accuracy if your measure of the 4 feet is not off by more than half an inch.

 

-----signature-----

More on the analysis of casting times:

Let's say that you are measuring speed by the time stamps in a DAOC log file (to eliminate the human error of stopwatch timing).

If your first event happens at time 1, and your second event happens at time 10, you might naively say that the interval is 9 seconds. What you *actually* know is that the first event happened sometime between 1.0 seconds and 1.9999... seconds. The second event, similarly, happened between 10.0 and 10.9999... seconds. The lower bound on your interval is 10.0-2.0, and the upper bound is 11.0-1.0. You measured 9 seconds, but you know *for sure* that your time is between 8 and 10 seconds.

You can use this kind of bounding to quantify how much the "real" value can differ from your single test average. The basic rule of thumb is that (t-1)/n < "real" speed < (t+1)/n, assuming that your log timestamps are correct.

Note that if we assume the cast speed is a constant, these boundaries are absolute. We will not glean any more absolute information about the "real" cast speed unless we find a test with a higher min or lower max boundary value.

One way to do this is by running more tests (and longer tests), but you can actually get more use out of your existing data as well. When you log a test to file, you have the time stamp on every intermediate spell cast. This allows you to measure n * (n + 1) / 2 total casting intervals -- the first cast to every future cast, 2nd cast to every future cast, etc. If you determine the min/max possible speeds for each of these intervals, you might find a closer bound than if you only look at the first and last times.

Obviously it's not a task to do by hand, but if you parse your log into a spreadsheet, it becomes pretty simple to fill in formulas that will give you the min & max bounds for every single intermediate interval. You can then take the "max of mins" and "min of maxes" to get the tightest possible bounds shown by your particular test.

This does come with one caveat: it all depends on the reliability of the timestamps in your log file. If there is some jitter as to when events are timestamped, that breaks the assumption that our data represents a constant cast time. The maximum and minimum values we find can be off by as much as the maximum jitter (variance in lag, application processing time, etc.). Though, with enough samples, the max and min should be off by the same amount on both sides, so their average should still be very close to the "real" speed. (This is a separate discussion; the implications are different depending on whether cast speed actually varies on the server side, or if the only variance is in the client's reporting. If the latter is true, a long enough test will spread out the jitter for the first & last measurements over a large number of intervals and effectively eliminate it.)

 

-----signature-----

Great info.


love to see the Break points for 9% and 8% cast spd temps.

 

-----signature-----

thats not a template

 

-----signature-----

Well ....this entire thread is about break points being the timing of your spells. And someone did say caster spd effected it ..... So it follows that now caster spd is in play for maxing a temp. More timers and more toa bonuses by giving up caster spd (which i might not even need) is a good thing. ...


ps nothing is a absolute... EG I would give up 1% caster spd for alot of things already ,if it doesnt effect me because of break points it kinda is a no brainer.

 

-----signature-----

I do stats & programming professionally. The number of replicates/same size for a required confidence level essentially boils down to how variable the data is, which in this case, isn't very variable. Without raw data on a per-cast basis I can't calculate the actual variance but I would expect 100 casts to be more than enough. Worth mentioning that cast time in DAOC is the same time every time (zero variance), it's really network/game lag producing the variability.

Something that hasn't been fully covered is the assumption that total dex is all that matters -- it might not be. Whether the dex comes from RAs, creation, TOA overcap etc may also play a part.

Also, the guy with the actual data always wins, especially vs hazy non-specific recollections of 6yo data.

 

-----signature-----

^^ Thank you dirty.

 

-----signature-----

I recently had an issue with some code where certain calculations were creating slightly different results than they were previously. I traced it back to a compiler upgrade and different compiler settings. What was happening was that certain fractional computations weren't being truncated as expected, but rounded. In mathematical terms, usually values below .5 are rounded down, and those above are rounded up.

Non-technically speaking: something could've changed in the settings somewhere during the Ywain upgrade that subtly broke certain calculations. I know it can happen, because it happened to me.

Several weeks before this thread was started, Mythic put up in one of their patch notes, some fix that was supposed to help with lag and make the client run better. They didn't mention what it was, but i'm about 99% sure that's where this change in cast time came from.

 

-----signature-----

Thanks Slajzer, this is awesome data you provided... I can't imagine all the tweaking of starting stats/ra's/gear you went through to boil it down to a single break point.


The change at the break points is so blatantly obvious (sometimes >10%) I don't really see how sample size can even be an argument, and I'm surprised you guys bothered arguing with whats his face for as long as you did.


Definitely bookmarking this thread and thanks again.

 

-----signature-----