# What the heck are the odds for purple hero??? page 2

35 posts

 839 posts Originally posted by gotoxy:How about adding some other perspectives. The odds for a purple can be way lower than 1/9000 but only PM knows the truth. All we have is a cap(max) for refresh to be sure that if you get SOL, you still can get purples. Im playing since november and i havent got a damn purple the first 3 months i played. Even blues was damn rare. From my exp, i get 1 natural purple each time i reach the counter twice. So for me its 1/18000 avg since when u reach the cap(Counter = 0) u get a purple, but those should not be counted in chance to get since they are reward (nothing to do with luck) if you read the change log PM had stated that the odd of blue/purple were 1/600 and 1/6000. Like you I had played since the first month and before the tavern refresh cap I barely found any purple hero’s (I think I had 3). After the tavern refresh cap was added, in the same change log section, PM noted that the odds for blue/purple were increased to 1/900 and 1/9000. Even still, as you’ve said, the only purples I’ve ever found since then have came from the refresh limit having been reached. 390 posts Originally posted by nvillian1:Originally posted by gotoxy:How about adding some other perspectives. The odds for a purple can be way lower than 1/9000 but only PM knows the truth. All we have is a cap(max) for refresh to be sure that if you get SOL, you still can get purples. Im playing since november and i havent got a damn purple the first 3 months i played. Even blues was damn rare. From my exp, i get 1 natural purple each time i reach the counter twice. So for me its 1/18000 avg since when u reach the cap(Counter = 0) u get a purple, but those should not be counted in chance to get since they are reward (nothing to do with luck) if you read the change log PM had stated that the odd of blue/purple were 1/600 and 1/6000. Like you I had played since the first month and before the tavern refresh cap I barely found any purple hero’s (I think I had 3). After the tavern refresh cap was added, in the same change log section, PM noted that the odds for blue/purple were increased to 1/900 and 1/9000. Even still, as you’ve said, the only purples I’ve ever found since then have came from the refresh limit having been reached. PM can say what he want.. there is no confirmation we can get. Remember the chest spawn odds… i had to make a full thread to prove PM was wrong… But having Dev doing work like this = ppl wondering where the thuth is. 22 posts Originally posted by branimirb:Dear prune. You’re wrong. As both a developer and a mathematician, I understand where you’re coming from in the sense that yes, given 300 tries in total with each having a 1/9000 chance of purple, the chance is 0.0328. However, when coding, not only is calculating a minute chance so many times in a row stupid, it’s also difficult to implement. Although your math is right, your understanding is off. The card gives a 300x (three hundred times chance) of getting a purple hero. Since the chance of getting purple normally is 1/9000, the chance of getting purple with the card is now 300/9000, or 0.0333. This is how any programmer would implement the code, simply because the alternative is not logical. tl;dr → The chances with purple are 0.0333, not 0.0328. Well, as a programmer it makes sense to do something silly like “if (random() > tavern_refreshes / 900.0) then generate_blue_hero();”. As a mathematician it makes sense to code things such that there is no advantage or disadvantage to check taverns frequently. In which case the implementation should be along the lines of “for (i=tavern_refreshes; i>0; —i) if (random() > 1.0 / 900.0) then generate_blue_hero();”. As-is the best thing to do is get a VIP card and refresh taverns as infrequently as possible, since the implementation is likely that which makes sense to an expert programmer and to a novice mathematician (rather than expertise the other way around). 542 posts from an average standpoint the two method make no difference, cause the “mathematician” method will have a chance to generate multiple blue/purp, thus while it have a lower chance of seeing one at all, the avg purp/blue generated over a set number of refreshes remain the same. thus there is no compelling reason to do it the resource expensive way (which all loops are) 839 posts Originally posted by Wyriel:Originally posted by branimirb:Dear prune. You’re wrong. As both a developer and a mathematician, I understand where you’re coming from in the sense that yes, given 300 tries in total with each having a 1/9000 chance of purple, the chance is 0.0328. However, when coding, not only is calculating a minute chance so many times in a row stupid, it’s also difficult to implement. Although your math is right, your understanding is off. The card gives a 300x (three hundred times chance) of getting a purple hero. Since the chance of getting purple normally is 1/9000, the chance of getting purple with the card is now 300/9000, or 0.0333. This is how any programmer would implement the code, simply because the alternative is not logical. tl;dr → The chances with purple are 0.0333, not 0.0328. Well, as a programmer it makes sense to do something silly like “if (random() > tavern_refreshes / 900.0) then generate_blue_hero();”. As a mathematician it makes sense to code things such that there is no advantage or disadvantage to check taverns frequently. In which case the implementation should be along the lines of “for (i=tavern_refreshes; i>0; —i) if (random() > 1.0 / 900.0) then generate_blue_hero();”. As-is the best thing to do is get a VIP card and refresh taverns as infrequently as possible, since the implementation is likely that which makes sense to an expert programmer and to a novice mathematician (rather than expertise the other way around). blue = random(900); purple = random(9000); for(i=0;i tavern_refreshes / 900.0) then generate_blue_hero();”. As a mathematician it makes sense to code things such that there is no advantage or disadvantage to check taverns frequently. In which case the implementation should be along the lines of “for (i=tavern_refreshes; i>0; —i) if (random() > 1.0 / 900.0) then generate_blue_hero();”. As-is the best thing to do is get a VIP card and refresh taverns as infrequently as possible, since the implementation is likely that which makes sense to an expert programmer and to a novice mathematician (rather than expertise the other way around). blue = random(900); purple = random(9000); for(i=0;i0) qualities[--i] = random(); // do four rolls per refresh` `heapify(qualities); // setup keeping only the top k heroes (where k == tavern_slots == 4)` `i=tavern_slots;` `while(i>0) heroes[--i] = generate_hero_by_quality(pop_heap(qualities)); ` where: `Hero generate_hero_by_quality(float r) {` `assert r >= 0;` `assert r < 1;` `if (r < purple_threshold) return new_purple_hero();` `if (r < blue_threshold) return new_blue_hero();` `if (r < green_threshold) return new_green_hero();` `return new_white_hero();` `}` However, this still has all kinds of problems (and does not, I think, convey the point any clearer). For one thing, odds such as 1/9000 are not exactly representable in binary floating point. For another, “purple_threshold = 1.0/9000.0;” is not even correct; that would produce rather more than 1 purple hero every 9000 refreshes. By a naive way of thinking, “purple_threshold = 1.0 / (9000.0 * 4.0);” addresses that subtlety; actually it should be “purple_threshold = 1.0 – pow(1.0 – 1.0 / 9000.0, 0.25);”. For yet another problem, the counter mechanic is not included; we need to track the rolls and decide how to address the guaranteed case (replace one of the random() calls with a preset number guaranteeing a particular color?). (It has yet further problems at a software engineering level, although this version is better in several respects (named constants rather than magic numbers, for example).) Fortunately, this is a game, not a piece of software intended for precise mathematical calculations. So not only do such problems not even matter, we don’t even need the whole loop. A one-shot implementation has the serious advantage of being sweet and simple: difficult to mess up in a grandiose fashion (like getting ones inequality signs in the wrong direction!). That the mathematics of the one-shot method are not equivalent to the loop method is an acceptable sacrifice; the distinction is beyond anyone without at least a semester’s worth of statistics in any case. Moreover the absolute magnitude of the deviation in expectation is smaller than any single player is likely to ever have enough data to notice or prove the existence of; at least with respect to purple heroes the difference between 30/9000 and 1 – (1 – 1/9000)^30 is too small to care about (about 5 parts in a million). (Even whole galaxies likely couldn’t amass enough purple heroes for the mathematics to matter (50 players, 30 heroes each…).) tl;dr? “Lazy programmer” does not mean “bad programmer”; lazy is often good. Fewer bugs ;). (The implementation of PvP WoH springs to mind…) Regarding strategy, regardless of implementation (mathematically-principled or software-engineering-principled): Frantically refreshing ones taverns as frequently as possible confers no advantage. Waiting until it is totally full also confers no in-game advantage worth speaking of (…unless one considers five-in-a-million to be an ‘advantage’). (Meta-game wise, of course, being able to wait is a huge advantage: get a VIP badge. It’s best feature is in the “+more”: +20 max tavern refreshes.) For reference, a truly in-game significant point made elsewhere (i.e., in the ultimate Q&A) is that it is worthwhile to keep one tavern at level 1. That really does make a strategic difference, at least to certain styles of play. 839 posts Originally posted by gotoxy:Originally posted by nvillian1:Originally posted by Wyriel:Originally posted by branimirb:Dear prune. You’re wrong. As both a developer and a mathematician, I understand where you’re coming from in the sense that yes, given 300 tries in total with each having a 1/9000 chance of purple, the chance is 0.0328. However, when coding, not only is calculating a minute chance so many times in a row stupid, it’s also difficult to implement. Although your math is right, your understanding is off. The card gives a 300x (three hundred times chance) of getting a purple hero. Since the chance of getting purple normally is 1/9000, the chance of getting purple with the card is now 300/9000, or 0.0333. This is how any programmer would implement the code, simply because the alternative is not logical. tl;dr → The chances with purple are 0.0333, not 0.0328. Well, as a programmer it makes sense to do something silly like “if (random() > tavern_refreshes / 900.0) then generate_blue_hero();”. As a mathematician it makes sense to code things such that there is no advantage or disadvantage to check taverns frequently. In which case the implementation should be along the lines of “for (i=tavern_refreshes; i>0; —i) if (random() > 1.0 / 900.0) then generate_blue_hero();”. As-is the best thing to do is get a VIP card and refresh taverns as infrequently as possible, since the implementation is likely that which makes sense to an expert programmer and to a novice mathematician (rather than expertise the other way around). blue = random(900); purple = random(9000); for(i=0;i