T3hasiangod wrote: »Because of reasons that have yet to be explained or expanded upon.
starkerealm wrote: »
In your case? Because you're a healer main. Probably the same answer for Asian. As a tank main, crits don't even exist in his world.
So you are arguing that ESO RNG is not particularly good at avoiding lucky/unlucky streaks, and you blame the used PRNG or seeds for that. However, a truly random RNG may eventually yield the same number many times (see the Tetris dilemma and why modern implementations of that game use a crooked randomizer that guarantees players will never receive more than four S or Z pieces in a row).starkerealm wrote: »I did not say, "bad," I said, "streaky." Moreover, I said all ESO RNG is streaky. Which, if you play, isn't really new information.
Apply this concept to the generation of a sequence of coin tosses and you may understand the relevance of it. You should suspect a coin is crooked if there exists a pattern to the coin flips that can be described by a program using substantially fewer bits than the sequence of flips itself.starkerealm wrote: »I think we're talking about something completely different here. The Kolmogorov Complexity I know has to do with the amount of code you need to generate an object, and how the code that goes into it will (almost always) be larger than the object itself. Which, I mean, it's true, but not particularly relevant to the discussion at hand. I suspect you're thinking about something else.
So you are arguing that ESO RNG is not particularly good at avoiding lucky/unlucky streaks, and you blame the used PRNG or seeds for that. However, a truly random RNG may eventually yield the same number many times (see the Tetris dilemma and why modern implementations of that game use a crooked randomizer that guarantees players will never receive more than four S or Z pieces in a row).starkerealm wrote: »I did not say, "bad," I said, "streaky." Moreover, I said all ESO RNG is streaky. Which, if you play, isn't really new information.
What I'm trying to say is: the observation of any form of streaks is not an indication of a problem with the RNG. Perceived randomness is not the same as true randomness. To make things feel fair you need to analyze previous results and pay attention to players psychology. Many games use statistics to correct unlucky streaks, but ESO seems not to be one of them. One way you can do this is to keep track of how many times an event has occurred and use that to bias the next number generated by the PRNG. Or, in other words, make the sequence less random (== reduce it's Kolmogorov Complexity).
Apply this concept to the generation of a sequence of coin tosses and you may understand the relevance of it. You should suspect a coin is crooked if there exists a pattern to the coin flips that can be described by a program using substantially fewer bits than the sequence of flips itself.starkerealm wrote: »I think we're talking about something completely different here. The Kolmogorov Complexity I know has to do with the amount of code you need to generate an object, and how the code that goes into it will (almost always) be larger than the object itself. Which, I mean, it's true, but not particularly relevant to the discussion at hand. I suspect you're thinking about something else.
starkerealm wrote: »FrancisCrawford wrote: »What exactly is being claimed to be nonrandom in practice here?
The issue isn't about something being nonrandom, simply there are issues which arise from attempting to model data outside of the game.
StytchFingal wrote: »A linked video stated that IA and UI are proc sets, and therefore can't crit. How is this so? Reading the 5th item bonus on each, I see no proc (programmed random occurrence, is that not the meaning?) condition attached to either set. Instead, they both seem to add flat damage to heavy attacks under specific, non-random conditions. Heavy attacks crit. Am I misunderstanding "proc", or the set bonuses, or both?
StytchFingal wrote: »A linked video stated that IA and UI are proc sets, and therefore can't crit. How is this so? Reading the 5th item bonus on each, I see no proc (programmed random occurrence, is that not the meaning?) condition attached to either set. Instead, they both seem to add flat damage to heavy attacks under specific, non-random conditions. Heavy attacks crit. Am I misunderstanding "proc", or the set bonuses, or both?
Damage proc values can't crit same goes for your monster sets. They're flat damage and are only increased by very rare values.
StytchFingal wrote: »StytchFingal wrote: »A linked video stated that IA and UI are proc sets, and therefore can't crit. How is this so? Reading the 5th item bonus on each, I see no proc (programmed random occurrence, is that not the meaning?) condition attached to either set. Instead, they both seem to add flat damage to heavy attacks under specific, non-random conditions. Heavy attacks crit. Am I misunderstanding "proc", or the set bonuses, or both?
Damage proc values can't crit same goes for your monster sets. They're flat damage and are only increased by very rare values.
So that implies the heavy attack damage added by UI and IA doesn't/can't crit, I guess? Any suggestions on ways to empirically test that?
On edit: so the game has to calculate on each heavy attack tick, the heavy attack damage, its crit chance, its damage if/when it crits, and the added non-crit heavy attack damage from IA/UI? Do I have that right? Seems very complicated to parse out what is doing what for sure, damnit.
FrancisCrawford wrote: »So what ARE you talking about?
The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
starkerealm wrote: »The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
No, you're referring to something else entirely by the wrong name.
it's pretty easy test actually, you turn on eso logs, light and heavy attack and dummy to death and you will see the numbers
T3hasiangod wrote: »starkerealm wrote: »The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
No, you're referring to something else entirely by the wrong name.
No, @Katlefiya is more or less correct. Based on this paper from 1999, it appears that the Kolmogorov complexity can be thought of as a measure of linear complexity. In other words, it can be used as a measure of randomness.
See also this.
In algorithmic information theory, the Kolmogorov complexity of an object, such as a piece of text, is the length of the shortest computer program that produces the object as output.
StytchFingal wrote: »@Heelie
it's pretty easy test actually, you turn on eso logs, light and heavy attack and dummy to death and you will see the numbers
ESO Logs separates the non-critable added heavy attack tick damage from the crittable tick damage? That's kinda awesome. I will have a look. Thank you.
starkerealm wrote: »T3hasiangod wrote: »starkerealm wrote: »The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
No, you're referring to something else entirely by the wrong name.
No, @Katlefiya is more or less correct. Based on this paper from 1999, it appears that the Kolmogorov complexity can be thought of as a measure of linear complexity. In other words, it can be used as a measure of randomness.
See also this.
A quick google search results in this:In algorithmic information theory, the Kolmogorov complexity of an object, such as a piece of text, is the length of the shortest computer program that produces the object as output.
Which you might notice, isn't even remotely similar to what @Katlefiya is trying to discuss.
As for whatever you linked, I really don't have the interest to pay out of pocket to get past the paywall on an academic journal I've got zero interest in. I get that you're, probably, still in college, but those of us who've graduated and actually left academia don't generally maintain those subscriptions.
T3hasiangod wrote: »1. I'm a doctoral student.
T3hasiangod wrote: »2. The second paper is free.
T3hasiangod wrote: »3. A simple Google or Wikipedia search on a term does not always explain its complexity or full usage.
starkerealm wrote: »T3hasiangod wrote: »1. I'm a doctoral student.
So, as I said, you're still in school. For those of us who actually graduated, we don't generally maintain subscriptions to academic journals, there really isn't much value in it.T3hasiangod wrote: »2. The second paper is free.
And, as with the abstract from the first, it actually built off of the concept. It was not part of the concept itself.T3hasiangod wrote: »3. A simple Google or Wikipedia search on a term does not always explain its complexity or full usage.
In this case, it gets enough of the context across. What @Katlefiya has been desperately trying to do is bundle subsequent analysis into the basic concept. Hell, the abstract of the paywalled paper is taking a pair of researchers to task for attempting to do exactly that.
starkerealm wrote: »FrancisCrawford wrote: »So what ARE you talking about?
@FrancisCrawford, a very short version for you? Don't trust statistical projections of performance based on out of game tools.
starkerealm wrote: »T3hasiangod wrote: »starkerealm wrote: »The definition of the Kolmogorov Complexity is pretty simple, I will give you that. But as I mentioned before, the Kolmogorov complexity is a wonderful measure of randomness, and to label it as "not particularly profound" is somewhat ignorant of it's implications for mathematical notions of individual randomness and complexity.starkerealm wrote: »Also, I went back and double checked. This isn't a concept that gets tossed around often, because it's kinda self-evident. I thought, maybe I was misremembering, but, no the Kolmogorov Complexity really is the whole thing about programs being longer than the strings they generate. It's not particularly profound, and it's not relevant. Less relevant than your coin flip analogy.
No, you're referring to something else entirely by the wrong name.
No, @Katlefiya is more or less correct. Based on this paper from 1999, it appears that the Kolmogorov complexity can be thought of as a measure of linear complexity. In other words, it can be used as a measure of randomness.
See also this.
A quick google search results in this:In algorithmic information theory, the Kolmogorov complexity of an object, such as a piece of text, is the length of the shortest computer program that produces the object as output.
Which you might notice, isn't even remotely similar to what @Katlefiya is trying to discuss.
As for whatever you linked, I really don't have the interest to pay out of pocket to get past the paywall on an academic journal I've got zero interest in. I get that you're, probably, still in college, but those of us who've graduated and actually left academia don't generally maintain those subscriptions.
T3hasiangod wrote: »starkerealm wrote: »T3hasiangod wrote: »1. I'm a doctoral student.
So, as I said, you're still in school. For those of us who actually graduated, we don't generally maintain subscriptions to academic journals, there really isn't much value in it.T3hasiangod wrote: »2. The second paper is free.
And, as with the abstract from the first, it actually built off of the concept. It was not part of the concept itself.T3hasiangod wrote: »3. A simple Google or Wikipedia search on a term does not always explain its complexity or full usage.
In this case, it gets enough of the context across. What @Katlefiya has been desperately trying to do is bundle subsequent analysis into the basic concept. Hell, the abstract of the paywalled paper is taking a pair of researchers to task for attempting to do exactly that.
This is so asinine, I wonder whether you are even willing to argue in good faith, or are so stuck that you refuse to see any other side of the argument.
An extension of a process or concept does not mean it is wrong. There are many processes or concepts that have been extended to define things beyond what the "basic" concept defines, and those extensions are still valid. Often, these are proven through mathematical or logical proofs.
Much like how multiplication is the natural extension of addition, you don't discount multiplication just because it isn't the same basic concept as addition.
Integrals, if you just look at the Wikipedia definition, "assigns numbers to functions in a way that can describe displacement, area, volume, and other concepts that arise by combining infinitesimal data."
And we do use integrals to describe and calculate the volume of three-dimensional objects and areas under curves. But we can go steps further and prove that integrals are actually infinite Reimann sums, or that we can use integrals to determine a probability function's possible random values.
Similarly, the basic definition of Kolmogorov complexity does not strictly dictate what it can or cannot be used for. As far as I can ascertain, Kolmogorov complexity can be used as a measure of randomness, and there have been proofs to show this.
But again, I doubt you have the actual willingness to read and learn on the topic.
FrancisCrawford wrote: »starkerealm wrote: »FrancisCrawford wrote: »So what ARE you talking about?
@FrancisCrawford, a very short version for you? Don't trust statistical projections of performance based on out of game tools.
Please pardon my lack of clarity.
I wasn't asking you to reiterate breezy, unsupported opinion. I was asking you for one or more substantive REASONS for your opinion, such as a not-conclusively-disproven hypothesis as to WHY straightforward calculations might be consistently misleading.
Do you have anything like that? If not, please pardon my incorrect assumption that your views were in some way backed up by solid reasoning, and I'll stop bothering you accordingly.
starkerealm wrote: »FrancisCrawford wrote: »starkerealm wrote: »FrancisCrawford wrote: »So what ARE you talking about?
@FrancisCrawford, a very short version for you? Don't trust statistical projections of performance based on out of game tools.
Please pardon my lack of clarity.
I wasn't asking you to reiterate breezy, unsupported opinion. I was asking you for one or more substantive REASONS for your opinion, such as a not-conclusively-disproven hypothesis as to WHY straightforward calculations might be consistently misleading.
Do you have anything like that? If not, please pardon my incorrect assumption that your views were in some way backed up by solid reasoning, and I'll stop bothering you accordingly.
Yeah, this one's actually pretty simple when you strip the guts out of it. Well, mostly, because there's two parts.
First, the game is idiosyncratic.
An example of this was back before Summerset released. While I was at ZOS, I remember asking if it was intended that the short duration poisons scaled with Master-at-Arms, while the lingering poisons scaled with Thaumaturge, and was told yes, that was intended behavior. I think I was asking Eric, but it's been over a year, So the answer may have come from Rich or Finn.
If you're going to model the game, you need to know all of the idiosyncrasies that affect your build. This isn't impossible, but does require you have a, frankly unrealistic, encyclopedic knowledge of how the game works. At that point, simply put, it's easier to prototype stuff on the PTS and test it, than it is to develop the model and run the numbers.
The poison thing is one example, there are literally hundreds of others, and some of these change with each patch. The introduction of Jump Points competently screwed up any previous CP models, and the entire false jump point thing is just a nightmare to test. If you're trying to model the game, all of this stuff becomes immediately relevant.
Further, this stuff distorts people's understanding of how the game works. One of the funnier examples were the cries about how bleeds were buffed this summer. Fact is, if you were running heavy bleed set ups in PvP before that, you took a nerf. The reason is that bleeds used to ignore resists. They were flagged like Oblivion damage, and so the damage on the tooltip was the damage your enemy would take. Also, at one point, bleeds were actually bugged so they couldn't be cleansed.
So, here's a very specific question, and if you can't answer it off the top of your head, you should start to see why these idiosyncrasies are important for modeling: Can Undaunted Infiltrator (and Undaunted Unweaver) crit?
This might sound like a stupid question. Of course, proc sets cannot crit, and UI is a proc set.
Except, UI doesn't, actually, deal damage. It causes your light and heavy attacks to do more damage. Normally, your light and heavies can crit. And we've seen in other cases (such as imbue weapon) that abilities (and buffs) that modify your light and heavy attacks simply bake into those attacks, and those attacks can still crit.
So, if your first response was, "no, that's stupid, of course it can't," you should start to be able to see why modeling this externally is more trouble than it's worth. (You'd also be wrong, because the bonus damage is baked straight into your light and heavy attacks, just like with a number of other sources that modify your basic attacks.)
The second part is data collection in the model. Specifically how it handles crits and other procced effects. This is what that whole coin flip thing was about. Basically, if you're going to model a random chance, and "make it real," that is to say, produce enough examples for it to, statistically, even out so you can just use the chance as the frequency without worrying about anything weird happening, you need a lot of data.
Okay, fine. Combat generates a lot of data? Most of your attacks can crit. So, that's a lot of chances to say, "well, something should crit."
Problem is mashing all those data sets together into a single collection of data. If you have 1700 points of data, it should be within a couple percent of "true." But, that's not what's actually happening. You have, maybe 50 data points for that set, 120 for this set over here, 35 for that one, and less than a dozen on this effect. The result is, even though there's enough data overall, you can't just mix it all together and say, "everything should work out." Your margins for error will be extremely high, and the modeling won't really work reliably.
It's kinda like throwing your entire dinner in the skillet at once, and trying to cook it together. In certain circumstances, it'll be fine, but most of the time, you'd be mixing things in that need to be handled separately. (Yes, I hate using metaphors like this, especially since I tend to cook one-skillet meals, but, here you go.)
Does that help to explain the issues here?
FrancisCrawford wrote: »OK. That makes more sense, up to a point.
You are correct that tooltips can be vague, ambiguous, misleading or flat-out wrong. You are right to suggest, in effect, testing each tooltip separately.
But assuming you play on the PC or Mac, I don't understand your pessimism about testing multiple tooltips in a single parse, if your main reason for pessimism is the unpredictability of short-run crit percentages. After all, add-ons give separate crit rates for each skill.
Yes, code is wonky, things that seem like they should give numbers from a certain set of choices give other numbers entirely, etc. But I see the real problems as lying in tooltip inaccuracy, game code bugs, similar problems in add-ons, and/or lack of repeatability in actual player actions during tests. (Un)Lucky streaks in crits would be quite far down on my list of concerns.
kylewwefan wrote: »Honestly, it blew my mind that someone would know who I am!
starkerealm wrote: »FrancisCrawford wrote: »OK. That makes more sense, up to a point.
You are correct that tooltips can be vague, ambiguous, misleading or flat-out wrong. You are right to suggest, in effect, testing each tooltip separately.
But assuming you play on the PC or Mac, I don't understand your pessimism about testing multiple tooltips in a single parse, if your main reason for pessimism is the unpredictability of short-run crit percentages. After all, add-ons give separate crit rates for each skill.
Yes, code is wonky, things that seem like they should give numbers from a certain set of choices give other numbers entirely, etc. But I see the real problems as lying in tooltip inaccuracy, game code bugs, similar problems in add-ons, and/or lack of repeatability in actual player actions during tests. (Un)Lucky streaks in crits would be quite far down on my list of concerns.
To an extent, it's the other way round; I'm extremely pessimistic about modeling a build's performance from outside of the game.
When it comes to actually testing builds, you're correct, you can't pull meaningful data from a single parse, you're going to be doing this for awhile. Streaks only become a real factor in testing when someone's fishing through their combat metrics data looking for, "that perfect parse," where the stars aligned. (And, yes, people do that. I've seen way too many parses where their crit frequency is more than 10% higher than their actual crit chance.)
I'm just going to throw this one out there, but, if you can't pull the rotation for a build, you can't run the build in live content. That might sound harsh, but, you do need to be able to just execute it on command. If you can't, then you'll actually get more value out of your dummies as rotation practice. There's nothing wrong with this, we all started there, but it is a different use for the tools.
All that said, even when you know what you're doing, you'll have the occasional parse where stuff just doesn't play. Everybody's been there. You're off rhythm, your abilities aren't firing, you're accidentally double casting your targeted ground AoEs, ect. We've all been there, and there's no shame in that, but you learn to toss those those parses. It's not a fault of the build, it's just butterfingers. And, hell, it happens in live content too.
The issue I take with crit isn't, actually, crit, it's that comment from the "rebuttal" video about, "making crit real." From a modeling perspective this is fine, you don't need to actually simulate a collection of crit rolls, you can just take the crit chance and say, "this is how often it happens," and, that will work in some other MMOs. Problem being that you can't model ESO. This is followed with the part where, "making it real," is statistically possible, with enough data, it should even out, but it requires a much longer combat duration that the video maker seems to understand. Like I've said, we're talking a minimum of 15-20 minutes of continuous combat. (And, in a lot of cases, it would, realistically, take over 30m.)
The streakiness is, kinda, a sideshow, because it does mean, in some cases, you can never, "make it real." That specific part of the video is what I was responding to.
You do realise that the comment about true crit chance was made about MMOs in general?