pDIF testing and Damage formulas

[pchan]

When analysing different DDs/setups/etc avg damage is what matters, so finding out how that works would be more useful than finding out the exact min/max's themselves imo.
.

I agree mostly with this, but it was shown that critical hit don't average around the average pdif for them.

[Yarko]

I agree mostly with this, but it was shown that critical hit don't average around the average pdif for them.

That's what i'm saying, with avg pDIF I don't mean (pDIFmax+pDIFmin)/2, but the actual avg pDIF: avg parsed hit / base damage.

[Masamune]

Looking at it from a programmer point of view:
the pDIF formulas seem to be all in the format of a * Ratio + q

the "a" variable (slope) is most likely not randomized (but probably changes depending on the value of Ratio), while q is the random variable that makes damage vary.

Exactly what i thought too when i 1st saw how my parses graphed.

the "a" variable could well be a fraction, and thus be decimal. It could be quite complicated to find out the exact value of it. The randomized q variable, though, probably has a lower and upper limit which don't have more than 2 decimals (e.g. qmax = 0.25; qmin = -0.75).

That's what i tried too when trying different values for a and q, but i tried to get resulting damage values as close as possible from the parsed ones, without getting "non-matching" dmg (like lower than one of max dmg parsed) and with as less "missing" values as possible. Sure i could try more extreme values for a and q but "simplier", and then i would have an accuracy near 0% (too much missing values, or worse: impossible to reach).

the actual avg pDIF: avg parsed hit / base damage.

Deviating from the goal of the topic there... Personnally, i really think that kind of thinking should come AFTER determining how damage works. Please let's do things in correct order.
Also, other problem with aiming for an accurate average implies always very high sample size (cf. the formulas used to determine minimum sample size to get 95% certainty on parsed crit% average). So far, all those parses have a sample size rangeing from 800 to 3300 normal hits and 200 to 1k crits, that's extremely poor in terms of 95% certainty for an average (but apparently enough to prove existence of most extreme values?). In other words, current parsed averages are unexploitable.

So do you want me try for "simplier" values for a and q, regardless of accuracy with parsed dmg? or continue a bit those parses in hope to get more missing values ? or try litterally another different model (I've included in last spoiler the pDIFmedians and widths, maybe could do something with them)?

Also, there is something else i don't know if you guys noticed: the "floor" @ Ratio=1.25-1.5. Doesnot that disturb your minds ? I remember that /checks are at Ratio < 1 for HighDef and Ratio > 1.25 for LowDef. That would have make sense if those pDIF curves were all "translated" of -0.25 to the left don't you think ? Just a thought, i really don't understand that weird "floor"...

[Miraun]

Awesome info Masamune, however I won't stop duplicating your efforts on my own DRG spreadsheet

I noticed in your assumptions on the fSTR. I wanted to verify that this is the same fSTR that is documented over in http://wiki.ffxiclopedia.org/wiki/FSTR

So, to validate my understanding of the OP, we now have working pDif equations for normal hits versus crits for 1H where Cratio > 1.05, and for 2H where Cratio > 1.4

Awesome job finding this out for the community!

[Masamune]

XD np Miraun, guessed something like this would happen, but meh why keep all that work for myself ? Especially after some of BG members helped me greatly for the crit% test. Btw if you find any mistakes while "duplicating", try to tell me ^^.

Regarding fSTR i didnot even used the wiki fSTR but a variant:
fSTR=IF(dSTR>14;
IF(INT((1/4)*dSTR+1)<dSTRmin;dSTRmin;IF(INT((1/4)*dSTR+1)>dSTRmax;dSTRmax;INT((1/4)*dSTR+1)));
IF(INT((1/5)*dSTR+2)<dSTRmin;dSTRmin;IF(INT((1/5)*dSTR+2)>dSTRmax;dSTRmax;INT((1/5)*dSTR+2))))
(apparently, there s a changing slope between -15<dSTR<15, but i didnot test)

which means basically the same thanks to the flooring, and is a nice example on topic: quite a number of values for a and q still works after flooring in terms of matching expected results. Question is "are this correct?"

IMO, JP dudes who tested that most certainly used the "floor" @ ratio 1.25-1.5, parsed their extreme min dmg @ different STR on same mob. Problem i don't know if they were aware of: if they indeed used that method, then most probably faced also the same flooring "problem" we have here.
Consequence for us: another flooring error to add to the one we can't avoid here, thus the asumption i made.

[Masamune]

Another point of view would be taking 2 "known" points to get the slope for one of the curves:

so for pDIFmin we know to have:

pDIF=1 @ Ratio=1.5
pDIF1H~1.57 @ Ratio=2       => a1H = 1.14    q1H = -0.71
pDIF2H~1.87 @ Ratio=2.25   => a2H = 1.16    q2H = -0.74

Verification with my parsed dmg:
for 1H: 80% accuracy, but 2 non-matching values @ Ratios=1.843+1.574
for 2H: 60% accuracy, but 5 non-matching values...

...so nvm, was just to get an idea for Yarko what is it "to use your head" for simplifying things, guess i fail at that XD

EDIT: after a bit playing with a and q, obtained 92.3% accuracy (only one missing value, full match otherwise) with a=86/75 and q=-29/40=-0.725 for 1H.
For 2H, those a/q values give 45.5% accuracy: full match until Ratio=1.805, then missing values above (all only -1 dmg difference).

EDIT2: a=23/20=1.15 and q=-0.73 works too for both 1H & 2H with slightly better accuracy (2 more matching values for 2H).

[Yarko]

I'm working on your data too but before I post any results (if i actually manage to get anything significant) I wanted to give you a couple advices for further precision:

- don't let excel approximate Ratio value to 3 digit, as like everything else in the game, it's probably floord and not approximated (I mean 1.0019 is 1.001 and not 1.002 as excel would give). To do this just use floor((atk/def)*1000)/1000 to calculate your ratio value, instead of simply atk/def.

- Lowest/Highest hits get influenced by flooring:
suppose Base Damage * real pDIF min = 100 * 2.009 = 200.9
this would get floord and would show as 200 on the logs, and when we calculate what we think is the lowest pDIF min value we do dmg / BD = 200 / 100 = 2.000.
We think the lowest pDIF min value is 2.000 when it's actually higher, 2.009.
Same thing happens to highest hit and pDIF max.
What I did to solve this problem was adding +1 to all the lowest hits/highest hits, and then calculated pDIF min using those values (again flooring at 3 digits using the *1000 and /1000 trick).

[Byrthnoth]

If you don't want to do *1000)/1000, you can just do Floor(value,.001)

[Masamune]

- don't let excel approximate Ratio value to 3 digit, as like everything else in the game, it's probably floord and not approximated (I mean 1.0019 is 1.001 and not 1.002 as excel would give). To do this just use floor((atk/def)*1000)/1000 to calculate your ratio value, instead of simply atk/def.

- Lowest/Highest hits get influenced by flooring:
suppose Base Damage * real pDIF min = 100 * 2.009 = 200.9
this would get floord and would show as 200 on the logs, and when we calculate what we think is the lowest pDIF min value we do dmg / BD = 200 / 100 = 2.000.
We think the lowest pDIF min value is 2.000 when it's actually higher, 2.009.
Same thing happens to highest hit and pDIF max.
What I did to solve this problem was adding +1 to all the lowest hits/highest hits, and then calculated pDIF min using those values (again flooring at 3 digits using the *1000 and /1000 trick).

Excellent, Yarko that's exactly what bothered me.

Regarding the excel trick, indeed i've just used Ratio=Attk/def, then Excel just auto chose the # of decimals to display depending on the width of my columns :S When i copy pasted here i manually SUPPR'd the exceeded decimals, maybe i shouldnot have :s

I can understand adding +1 to highest hits, but for lowest hits why not -1 ?

As for what Byrthnoth said, yes i used that TRUNCATE(X+0.0001;0.0001) and TRUNCATE(X-0.0001;0.0001) function to get X=parsedDMG/BaseDMG range after division in the pDIF caps study, but not here. i didnot bothered since i chose to do multiple parses with relatively low sampling then a simple tendency line since pDIF looks to be still linear like before updates.
But yep maybe Yarco is correct, i 'll check later i gtg...

[Miraun]

XD np Miraun, guessed something like this would happen, but meh why keep all that work for myself ? Especially after some of BG members helped me greatly for the crit% test. Btw if you find any mistakes while "duplicating", try to tell me ^^.

Regarding fSTR i didnot even used the wiki fSTR but a variant:
fSTR=IF(dSTR>14;
IF(INT((1/4)*dSTR+1)<dSTRmin;dSTRmin;IF(INT((1/4)*dSTR+1)>dSTRmax;dSTRmax;INT((1/4)*dSTR+1)));
IF(INT((1/5)*dSTR+2)<dSTRmin;dSTRmin;IF(INT((1/5)*dSTR+2)>dSTRmax;dSTRmax;INT((1/5)*dSTR+2))))
(apparently, there s a changing slope between -15<dSTR<15, but i didnot test)

which means basically the same thanks to the flooring, and is a nice example on topic: quite a number of values for a and q still works after flooring in terms of matching expected results. Question is "are this correct?"

IMO, JP dudes who tested that most certainly used the "floor" @ ratio 1.25-1.5, parsed their extreme min dmg @ different STR on same mob. Problem i don't know if they were aware of: if they indeed used that method, then most probably faced also the same flooring "problem" we have here.
Consequence for us: another flooring error to add to the one we can't avoid here, thus the asumption i made.

I love that you replied to me in if statements :3

[Julian]

Some people have better things to do than kill hundreds of level 1 mobs or don't even have the time to? Oh, did I mention I don't know how to make excel programs or any kind of pc program? Yeah, "go do it yourself" mentality ftw.

I would imagine that the "go do it yourself" mentality would include using this little website known as google.com for finding out how to use excel or how to program.

just ignore me I like what you guys do and appreciate it

[Yarko]

a = 1 qmax = +1.5 qmin = +0.625 seems to fit 2H crit data almost perfectly, but I can't find a reasonable combination that gives good results for 2H normal hits :/

[Masamune]

Not far Yarko ^^

For crit mins 2H i ended up with a=1 qmin=0.626, to get best accuracy of 33.3% (only 5 matching dmg /15) (qmin=0.625 still gave me same accu)

For crit max 1H AND 2H on other hand, a=1.03 qmax=1.45 gave 100% match for 2H, and 73.3% for 1H(6/16 missing values)

but for crit mins and Normal max for both 1H/2H, i admit i didnot find a/q with decently enough accuracy. i wonder how you got "almost perfect" while i get 33.3% with the a/qmin you proposed ?

Another question i would like to ask is: which set of parses do you think really need more samples (ie have too much missing suspected values)?

[Yugl]

Masamune, a few questions:

1. Is there any way to get your damage calculator to work for Excel 2003? I thought it would work, but it seems I cannot open the file properly.

2. What else is needed in terms of "testing"?

[Hakamaru]

First of all nice tests and interesting results.

I refuse to think they added formulas with so many decimals, the formulas must be a bit easier.

Not trying to be contrary or anything, but the formula will (most likely) not be pretty in a decimal representation. It's probably calculated using fixed-point integer math so that they don't have to ship every calculation off to a comparatively latent Floating Point Unit (not to mention there are FAR more integer functional units available in a modern x86 processor). The game designers are shooting for something here that's fast and deterministic... not necessarily accurate.

- don't let excel approximate Ratio value to 3 digit, as like everything else in the game, it's probably floord and not approximated (I mean 1.0019 is 1.001 and not 1.002 as excel would give). To do this just use floor((atk/def)*1000)/1000 to calculate your ratio value, instead of simply atk/def.

I would say you should chunk the numbers out to as many decimal places as possible and then try to back-figure the fixed-point representation after the solution converges. The "flooring" term people seem to throw around on FFXI forums is actually an artifact of using fixed-point math. Low order bits get shifted off the end of the world every time a multiplication is performed (note: multiplications may have one or more operand <1).

It's only going to make sense if you calculate things the same way the game does (using fixed-point). You should be able to get a pretty good approximation using decimal terms, but every time there's a multiply in your formula, it's going to deviate from the fixed-point solution just ever so slightly more.

[Masamune]

It's only going to make sense if you calculate things the same way the game does (using fixed-point). You should be able to get a pretty good approximation using decimal terms, but every time there's a multiply in your formula, it's going to deviate from the fixed-point solution just ever so slightly more.

Yes true, i started my dmg excel calc in that mind, but then... since noone proved with certainty the modus operandi of each math calculations from FFXI.exe, i were like... bah let's see what it gives.... sure isnot what i wanted.

Can you please give us an exemple of "fixed point" calculation, and resulting artifacts that may occurs ? i'm not sure to understand plainly.

Masamune, a few questions:

1. Is there any way to get your damage calculator to work for Excel 2003? I thought it would work, but it seems I cannot open the file properly.

2. What else is needed in terms of "testing"?

1. Didnot get much returns so hard to know if v4.1 works, but normally v4.0.3 which is still on site should be 100% 2003 compatible, still missing lot of features of v4.1.
Regarding v4.1, for compat tests, i used an excel2003 with all SPacks possibles + a complementary tool called "Analizis tools" under Options for a single function (Most Common Denominator). Hope that helps some of you having same problem, if that's something else Yugl, please PM me ^^

2. I think Ratio < 1, gotta find a way to test that. Just tried yesterday THF/dnc on a lvl64 Lcolis with a Jupi Staff.... omg how horrible it was rofl 10 great mins to kill it with 20% HP left.
Something else that would be nice to test in parallel of this pDIF topic would be the fSTR function, since i'm not sure of what happens at other values of dSTR than when fSTR=0.

[Hakamaru]

Can you please give us an exemple of "fixed point" calculation, and resulting artifacts that may occurs ? i'm not sure to understand plainly.

This is a good place to start, assuming you have a good concept of binary representation.

http://en.wikipedia.org/wiki/Fixed-point_arithmetic

You could also read about floating point representation because if you can understand that, fixed point is just a simplification of floating point.

http://en.wikipedia.org/wiki/Floating_point

For an example, let's assume some random haste gear and calculate the adjusted delay of someone using a Hagun (450 base delay).

For haste values, refer to Kirschy's old haste post: http://www.bluegartr.com/forum/showp...51&postcount=1

Assume the player is wearing:
Ace's Helm : 4% (40/1024)
Speed Belt : 6% (61/1024)
Dusk Hands : 3% (30/1024)
Haste Spell : 15% (150/1024)

The values shown are precisely a fixed-point representation. That is when you crank the math, you assume a denominator of 1024. If there's a multiply, it's accompanied by a divide by 1024. The reason this works so well is because 1024 happens to be 2^10... which makes the division very simple (only a single cycle on most CPUs because you can replace it with a 10-bit right shift). If you have to do a real divide, you can be waiting quite a few cycles for the result to come back, and this delay can add up when you're trying to crank 1000s of these per second.

So now if you perform the delay adjustment with decimal numbers, it would look something like:

AdjustedDelay = BaseDelay * (1 - HasteTotal)
              = 450 * (1 - 0.28)
              = 450 * 0.72
              = 324.0

Ok, let's do the same calculation in fixed-point arithmetic. The place you'll see a deviation from decimal is the representation of the constants. 281/1024 is some ugly decimal number... which is why I say you shouldn't be upset by ugly constant terms in your decimal representation. This happens because (take Speed Belt for example) there's no precise way to represent 0.06 as x/1024, where x is an integer.

AdjustedDelay = BaseDelay * (1 - HasteTotal)
              = 450 * (1*1024/1024 - 281/1024)
              = 450 * 743/1024
              = (450 * 743) / 1024
              = 334350 / 1024

When we divide by 1024, we just drop the bottom 10 bits. The binary representation of '334,350' is:
101 0001 1010 0000 1110

The bolded bits are the ones that get dropped by the division by 1024. Which leaves us with a result of:
1 0100 0110 = 326

If we didn't drop the bottom 10 bits, we would end up with something that represents something like:

326.513671875

Notice this doesn't line up with the pretty decimal calculation we did. It's all in the name of letting a computer calculate these values quickly using low-level binary tricks.




Even after all that... I'm not telling you that you should worry about this. I think you should do your best in a decimal representation, and then when you get something that looks close to reality, we can try and fit the constants to fixed-point. Don't be upset if the constants look really nasty in decimal... that's really all you need to take away from my posts. It's not like the game is truncating things at 3 or 4 decimal places... the game is not working in a number base that can be perfectly represented by decimal.

[Yarko]

Not far Yarko ^^

For crit mins 2H i ended up with a=1 qmin=0.626, to get best accuracy of 33.3% (only 5 matching dmg /15) (qmin=0.625 still gave me same accu)

For crit max 1H AND 2H on other hand, a=1.03 qmax=1.45 gave 100% match for 2H, and 73.3% for 1H(6/16 missing values)

but for crit mins and Normal max for both 1H/2H, i admit i didnot find a/q with decently enough accuracy. i wonder how you got "almost perfect" while i get 33.3% with the a/qmin you proposed ?

Err I meant to say almost perfect accuracy for qmax (only 1 value missing), qmin not so much.

Another question i would like to ask is: which set of parses do you think really need more samples (ie have too much missing suspected values)?

2H data definitely needs more data with 482 attack; if our model is correct, qrange (pDIF max - pDIF min) should have the same value regardless of Ratio value (unless Ratio <1.5 of course, where pDIF min = 1) but it seems to be a bit lower with 482 atk, which could either mean that we have some missing values there, or that the base damage is incorrect (fSTR?), or even that our model is wrong. I'll go get my hands dirt and try get more samples with 482 attack.

I haven't even excel'd the 1H data yet as I'm more interested in 2H atm, so I can't help you there.

Btw can you please post the avg parsed hit/crit dmg I already asked for ? I wanna see what it looks like!

[pchan]

Assume the player is wearing:
Ace's Helm : 4% (40/1024)
Speed Belt : 6% (61/1024)
Dusk Hands : 3% (30/1024)
Haste Spell : 15% (150/1024)

The values shown are precisely a fixed-point representation. That is when you crank the math, you assume a denominator of 1024. If there's a multiply, it's accompanied by a divide by 1024. The reason this works so well is because 1024 happens to be 2^10... which makes the division very simple (only a single cycle on most CPUs because you can replace it with a 10-bit right shift). If you have to do a real divide, you can be waiting quite a few cycles for the result to come back, and this delay can add up when you're trying to crank 1000s of these per second.

So now if you perform the delay adjustment with decimal numbers, it would look something like:

AdjustedDelay = BaseDelay * (1 - HasteTotal)
              = 450 * (1 - 0.27)
              = 450 * 0.73
              = 328.5

Ok, let's do the same calculation in fixed-point arithmetic. The place you'll see a deviation from decimal is the representation of the constants. 281/1024 is some ugly decimal number... which is why I say you shouldn't be upset by ugly constant terms in your decimal representation. This happens because (take Speed Belt for example) there's no precise way to represent 0.06 as x/1024, where x is an integer.

AdjustedDelay = BaseDelay * (1 - HasteTotal)
              = 450 * (1*1024/1024 - 281/1024)
              = 450 * 743/1024
              = (450 * 743) / 1024
              = 334350 / 1024

When we divide by 1024, we just drop the bottom 10 bits. The binary representation of '334,350' is:
101 0001 1010 0000 1110

The bolded bits are the ones that get dropped by the division by 1024. Which leaves us with a result of:
1 0100 0110 = 326

If we didn't drop the bottom 10 bits, we would end up with something that represents something like:

326.513671875

The gear you used has 28% haste, so the first table should be

AdjustedDelay = BaseDelay * (1 - HasteTotal)
              = 450 * (1 - 0.28)
              = 450 * 0.72
              = 324.0

It still gives different final values of course (324 vs 326).


@ Masamume, the old formulas on wiki show fractions of */5 for the local slopes and */12 for the ranges of cratio.

Spoiler: show

if cratio <=6/12 then pdif_max:=0.4+6/5*cratio
> end if;
> 
> if ((cratio>6/12) and (cratio<=10/12)) then pdif_max:=1
> end if;
> 
> if ((10/12 <=cratio) and (cratio <=24/12)) then pdif_max:=1+6/5*(cratio-10/12)
> end if;
> 
> if (cratio <=15/12) then pdif_min:=max(0, 6/5*(cratio-5/12)) 
> end if;
> 
> if ((15/12<=cratio) and (cratio <= 18/12)) then pdif_min:=1
> end if;
> 
> if ((cratio<=24/12) and (cratio>=18/12)) then pdif_min:=1+6/5*(cratio-18/12)
> end if;

It's possible that the /12 and /5 is actually something like */1024 where you drop anything past the second decimal.

[Masamune]

Nope PChan: 6/5=1.2 exactly <- this slope is clearly wrong when comparing to data. As consequence the q values used in these equations are also wrong.

Thanks Hakamaru, so you would suggest us to 1stly continue like Yarko and me doing atm until we get a decimal-looking number for a and q greatly approching the datas, then "convert" those in /1024 fixed point format, to finally re-verify with the datas ?
Ok gotcha ! ^^ EDIT: actually, the problem with starting to think as fixed point would imply to convert pretty much everything we are currently using in that format ? ie our Attack and Mob's defense values, fSTR etc... ? Sounds a bit overcomplicated to me :s

For Yarko, yes i posted with the datas the "width" for all those parses (pDIFmax-pDIFmin) in hope they would be constant + discover the missing values. Sadly it looks like both normal hits and crits seem to follow a cone-shaped area, with width largest at low Ratio and narrowest at caps (at the exception of that freaking "floor" @ 1.25<Ratio<1.5). I hope i'm wrong.
If you plan to parse 482attack, please try to NOT use Berserk and keep str97, so we can compare. Also, run from anyone fighting a coli nearby you, or KParser will "lose" a part of damage if the other dude kills his Coli before you kill yours (in other words, avoid the message "OtherDude defeats The Lesser Colibri." when you fighting one).

and ok i'll post the averages with their corresponding errors...