110 pulls, 3 legos. With that sample size it should be 6-7. Maybe a bit more or less, but that amount should average out. Which it would, if the chance was 3%, not 6%.
3 legos would mean being incredibly unlucky 3 times in a row., which is improbable.
I think they just screwed up and put the wrong chance percentage in the description.
yeah, this is variance with a misuse and/or misunderstanding of statistics and probabilities, unfortunately.
with that drop rate no, 110 pulls shouldn't average it out. not only is that not how probabilities work but since each pull is independent of one another.
I understand statistics. The chance of that happening is very low.
It is not the first time that the lego rate has been low on these events for me, it allways seems that it takes a lot longer for a lego to drop than the stated rate suggests. So much so that I basically stopped doing them until this one. In the past I put that down to bad luck, since those were smaller total numbers, but this is a large enough data set.
If something is supposed to happen on average once every 16-17 attempts, and it consistently takes twice that, then the probability rate is wrong.
The events seem like a good deal for a spender, but if the stated rates are wrong then maybe not.
I think what is going on is that they are using the ancient/void code system, which uses a base of 200. Then they are setting the drop probablity at some value X, which in percentage is (X/2). In other words a value of 6 is 3%. But, in the description for these pool events they are using the value X as the percent, ie 6%, which is why it seems to disproportionately take many more pulls than you expect to get a lego.
Also, if you consider actual pricing, a lego with the pool shards are almost exactly half what a lego from ancients would cost, if the pool shards were actually doing a 6% drop rate. If they were really doing a 3% drop rate on the other hand, the dollar cost would be about the same.
Because the probabilty of a lego is 1 in 200. So that would be the base unit for calculating pull rates for all champs. They won't create a separate routine for everything, it will be a base of 200, with some value X being used to calculate the chance. So, for something like a 6% chance you would set X as 12, do a ran 1 200, and if the result is greater than 200-X then you do a second roll against a table of eligble lego champs. For epics the value would be Y, so a random roll between 200-X and 200-Y would do it's second roll against a table of eligible epic champs. If less than 200-Y the second roll is against the table of rares.
There is no percentage calculation, it is just a random number roll, and the outcome is determined by where that value falls within bounds set by the variables X and Y (or Z in the case of mythicals).
So, when they have an event that has different outcomes, such as a 2x, or sacreds, they just change the values of variables X, Y and Z.
I understand statistics. The chance of that happening is very low.
It is not the first time that the lego rate has been low on these events for me, it allways seems that it takes a lot longer for a lego to drop than the stated rate suggests. So much so that I basically stopped doing them until this one. In the past I put that down to bad luck, since those were smaller total numbers, but this is a large enough data set.
If something is supposed to happen on average once every 16-17 attempts, and it consistently takes twice that, then the probability rate is wrong.
The events seem like a good deal for a spender, but if the stated rates are wrong then maybe not.
you'd think that someone who has such a deep understanding of statistics as you do would know that such a small sample size often leads to faulty data.
you'd think that someone who has such a deep understanding of statistics as you do would know that such a small sample size often leads to faulty data.
Solution is very simple. Pool results from a number of players shard pulls into a larger sampling. Obviously not as easy as it sounds but yellamokara is on the right track and statistically he is correct though not elequently stated as each pull should result in an average of 6 percent but this will skew downward as you aren't pulling 100 shards at a time to actually see a 6 percent average but a 3 percent overall.
Playrium really needs to add a mercy/pitty to the mix. If nothing else to standardize the experience.
- Coag
Solution is very simple. Pool results from a number of players shard pulls into a larger sampling. Obviously not as easy as it sounds but yellamokara is on the right track and statistically he is correct though not elequently stated as each pull should result in an average of 6 percent but this will skew downward as you aren't pulling 100 shards at a time to actually see a 6 percent average but a 3 percent overall.
Playrium really needs to add a mercy/pitty to the mix. If nothing else to standardize the experience.
- Coag
Except that's not how this works. What yella is engaging in is trying to fit the evidence to his conclusion rather than the other way around, thus coming up with a convoluted theory about shard coding with no basis
Expected value =/ actual results, that is what this boils down to, combined with a woefully small sample size, ignoring the existence of outliers (see above post for outlier in other direction) and a laundry list of biases
will pass along the request for a pity system but I think that would see the drop rates of prisms get changed quite a bit
100 shards is not nearly enough. I did a quick simulation of 10 million instances of 100 pulls, and 15.3% of those resulted in 3 or less legendaries. 28.7% got 4 or less. Reporting bias makes it difficult to judge the actual probabilities based on anecdotal evidence. The roughly 1 in 7 people who got half (or less) of the expected result are far more likely to voice their displeasure than the 1 lucky person in my simulation that got 23 legendaries from their 100 attempts, even though that's significantly more unlikely than getting 0 (which happened in 20334 instances, or about 0.2%), by several orders of magnitude.