Reply to thread

Message: <blockquote data-quote="Ovinomancer" data-source="post: 7892618" data-attributes="member: 16814">Actually, the graph should look like this:[ATTACH=full]117443[/ATTACH]And that's because you're graphing physical things - the 2*3d6 data DOES NOT EXIST except at certain points.  I graphed the -11 vice your correction for simplicity and to avoid explaining how your correction causes this graph vs the -10 graph to exist half of the time resulting in a bit of a Schrodinger's graph.  It's all bad assumptions.You've still tossed half of the d20 data if you compare where the 2*3d6 curve actually exists.  The 2*3d6 curve DOES NOT EXIST at half the data points you're comparing.  It creates discrete data points spaced 2 apart.  You can't use a model of a physical event non-physically and get coherent answers.Yes, it DOES NOT EXIST, yet you're using it as part of your comparison.This is a game that often hinges on a 5% difference and you're willing to cavalierly ignore the impact of 3% (and it's larger than that) just because you did mathemagic and can't acknowledge that's it's flawed.  This is, of course, ignoring the parts where it's up to 95% different.I bolded the problem in your thinking I've been trying to point out.  If you round down when halving, then rolling a 2 is the same as rolling a 3, rolling a 4 is the same as rolling a 5, etc, etc.  You've tossed half of your unique rolls using this method because you're ended up at the same result for comparison to rolls you aren't tossing on a 3d6.And, yes, [USER=72555]@NotAYakk[/USER] had some small concessions that made their changes to modifiers make those fractions occasionally count (they didn't double attribute bonuses outright, and random die could still produce odd results), but quite a number of modifiers fit the straight doubling model that results in losing half the numbers on the d20 due to rounding.  And the graphs certainly lose the data.You're losing 10% of the possible results, probability-wise.  Not 3%.  Focusing on a single delta as if it stands in for the total fidelity loss is not kosher.Except half the unique die rolls, again.They are not.  I provided an example earlier, a very slightly modified version of the OP example, that resulted in an infinite difference because it was still possible on 3d6 but wasn't possible at all on the modified d20 scale.  I also showed how moving in the other direction (and following the maths as presented in the OP) we encountered ~10% deltas between outcomes (notable, when you need an 8 or better on 3d6 using normal modifiers).There's nothing unphysical about any of this. It's all something you could do in your game. Either (1) roll 3d6 to resolve checks, double the result, and subtract 10. If the result ties the DC, confirm success with a d2; or (2) roll 1d20 to resolve checks, as written. The claim is that these produce very similar success probabilities, regardless of the DC.Alternatively, if you want luck to play less of a role in your game, you can either (1) roll 3d6 to resolve checks, confirming ties with a d2; or (2) roll 1d20, halve the distance from 10 and then add 10; or (3) double all bonuses and stretch DCs to be DC' = 10 + 2*(DC - 10). (2) and (3) are exactly identical; (1) is very close, at all DCs.Any of these are things you could actually do; they're not impractical thought experiments.</blockquote>No, you get the graph I showed because the 2*3d6 only exist on even numbers, so the difference when only the d20 exists is vast.  If you look at the dots very close to zero, they map to your graph -- I just unsmoothed it from you ignoring the fact that it's a discrete comparison of data points at places where one set does not exist.The above is just another way for you to extrapolate values where they don't exist that's less smooth than your first presentation.  It's still incorrect because data does not exist at those points.I've tried to not discuss your confirmation mechanic because it doesn't fix the underlying problem - it's another arbitrary kludge on bad math that tries to correct for the centering problem but doesn't address the lack of data problem.  I was hoping, apparently forlornly, that you'd catch onto the missing data problem and but I underestimated just how proud you are of that kludge.  It's actually kind of clever, if it weren't just putting lipstick on a pig.You originally presented it as a centering correction because Anydice won't let you create an impossible set of rolls by having rolls be .5.  I expect R is just fine with doing this, so I'm not sure why you didn't just center on 10.5 directly -- I'd guess that that put data points on the halfs and you instinctively realized that might be a problem, but I might be a bit optimistic about that given how you're generally okay using smoothed curve values at non-existent data points when it suits your purpose.  That said, you decided to create your confirmation correction mechanic with an eye towards having the distribution center on 10.5 by adjusting outcomes after the happen from the true center of 11.  As such, your mechanic is somewhat clever, but it's post hoc adjustment of data to fit a conclusion already formed, so bad practice and worse stats.  What you seem to think solves the problems nicely does no such thing for any of the problem except the apparent centering at 10.5.For instance, you suggest it corrects for no odd numbers in the 2*3d6-10 distribution.  But it doesn't, because, even with your addition that a failed confirmation actually means you reduce the roll by one, that odds of rolling an 11 in this is the odds of rolling exactly a 12 when needing a 12 and failing the confirmation.  Assuming only values that can be rolled are rolled, and assuming that the needed rolls are uniformly distributed (you can use other priors, up to you), then the probability of needing a 12 is 1 in 16 (there are 16 possible values on 3d6 from 3 to 18).  The odds you actually roll a 12 are 27/216.  The odds you fail to confirm are 1/2.  So, that's 1/16*27/216*1/2 or 27/6912 or a tiny, tiny under 0.4%So, you're claiming that your confirmation mechanic solves the no odd numbers because things will line up about 1% of the time?  Granted, that's based on an even distribution of target numbers across the possible values, which I actually limited to the ones you can roll rather than the ones inbetween the rolls (I didn't account for needing an 11, for instance, because you can't roll it).  Feel free to make different assumptions, like maybe ALL target numbers are 12, in which case 11 exists 27/3456 or 0.2% of the time.  That's best case for 11 existing, by the way, 0.2% of the time.Yeah, I haven't much talked about your confirmation mechanic, largely because it's a pointless distraction that fixes the centering without correcting the serious flaws in your analysis.  Centering was never the serious flaw.  Misaligned data sets and truncated tails are.[/QUOTE]

Verification