erstauning!

Forum Index > SC2 General |
qiza
Germany37 Posts
erstauning! ![]() | ||
Sweetfrost
Sweden211 Posts
| ||
MysticaL
Canada118 Posts
![]() | ||
Phael
United States281 Posts
I just got promoted from Diamond to Master's league (was Masters when Sc2 came out but stopped playing for about 6 months and recently came back). My MMR for the last 5 games I played - all of which I won: 73 +/- 16 (not sure what's up with this one) 129 +/- 16 78 +/- 16 -13 +/-16 -40 +/-16 Roughly 60% of my past 30 games have been against Master's opponents, and I went 19-11 in those thirty games. | ||
lIlIIlllIIlll
11 Posts
| ||
dextrin303
Sweden320 Posts
![]() | ||
-Aura-
United States209 Posts
| ||
Not_That
287 Posts
On May 12 2012 05:08 -Aura- wrote: Ok, I'm in diamond and I just played a master. I did all the stuff, and I got -89/-121. Does that mean how far I am from master? Can I figure out how far I am up in diamond? Is there anything useful I can do with his information lol? Sure. It means you're roughly 130 points below Diamond-Master line, and probably around 160 points or so from a promotion provided you can get it and keep it for a long enough period of games. As for doing anything useful for this information, you could sell it on ebay. | ||
-Aura-
United States209 Posts
On May 12 2012 08:57 Not_That wrote: Show nested quote + On May 12 2012 05:08 -Aura- wrote: Ok, I'm in diamond and I just played a master. I did all the stuff, and I got -89/-121. Does that mean how far I am from master? Can I figure out how far I am up in diamond? Is there anything useful I can do with his information lol? Sure. It means you're roughly 130 points below Diamond-Master line, and probably around 160 points or so from a promotion provided you can get it and keep it for a long enough period of games. As for doing anything useful for this information, you could sell it on ebay. Good man ^^. How many points away from the plat- diamond breakoff? Or is there no way to know that? (I've been diamond since season 1, it would be cool to know how much progress I've made) | ||
![]()
Excalibur_Z
United States12235 Posts
Let the monkeywork resume! | ||
Phanekim
United States777 Posts
so kudos to the people that do dedicate the time! lol. | ||
FairForever
Canada2392 Posts
On May 15 2012 03:41 Excalibur_Z wrote: FYI: The F function is not linear. Sent you a PM in greater detail. Let the monkeywork resume! uh oh... never good news to hear this... | ||
skeldark
Germany2223 Posts
On May 15 2012 08:44 FairForever wrote: Show nested quote + On May 15 2012 03:41 Excalibur_Z wrote: FYI: The F function is not linear. Sent you a PM in greater detail. Let the monkeywork resume! uh oh... never good news to hear this... I had the feeling it cant be linear just from the way skillfuctions work. But this function should still give good results as long as the changepoints are not to far away from 0 (+-12) We did not analyse the data yet because my tool had to many bugs to be secure. But so far we did not find data where this f function is wrong. ( if you dont trust data from guys with very few games because i think there is a special rule for them) i have data of different leagues that show very good graphs/results using it. So it must raise very slow at the beginning. What makes sense if you think about what this function try to do. | ||
celeryman
United States54 Posts
This paragraph (bolded especially) needs explanation: Before I could plot them on a single graph I had to normalize the results of the 7 different players by adding a different value for each (representing their individual MMRs). When I did that I was able to get a graph that was fairly linear. Now that there's some suggestion the point-to-mmr function is not linear (because why would it be really... the entire Trueskill system works on a basic gaussian distribution function; the core math of trueskill is PDF and CDF functions) this especially makes me wonder what you were doing. Did you just take 7 player's points, assume they had the same mmr (you say that), then add arbitrary point values to each until the curve was linear? If I can add arbitrary values to raw data I can make any function linear. The second thing I think you were doing, but seemed to be unstated, is using only masters/GM players, because those are the only leagues without division offsets. That seems fine because otherwise the divisions offsets can screw up your calculations. However... if you stick with purely intra-league matchups, you should be able to average out those differences if you can get enough game observations. My final question is a practical one. The bonus pool as well as the data-gathering methods make this process all cumbersome. One issue is if I want to track the last 10 games of a player, I have to work backwards, adding and subtracting points as I go, and I have to make the correct assumptions about the bonus pool as I do it. If you have the exact times available to you, this is possible. But the in-game display system starts to round the times after 24 hours, (i.e. 1 day ago, 1 week ago, 4 weeks ago, 6 weeks ago, etc.). So your bonus pool calculations have got some serious error introduced into them when you get beyond 24 hours. And even if you did take the exact times into account, it takes some fiddling to do the bonus pool calculations too. Did you incorporate those factors into your original calculations? There is something very valuable here, and I think it's possible to get close to what you're talking about, at least on relative terms, but could you re-state your original methodology with a little more precision? | ||
Not_That
287 Posts
On May 17 2012 04:38 celeryman wrote: If this thread is still alive, I'd like to ask some questions about this initial methodology because there's some things that are not clear about it. I also looked over some people's code and I'm not certain about some of the assumptions. This paragraph (bolded especially) needs explanation: Show nested quote + Before I could plot them on a single graph I had to normalize the results of the 7 different players by adding a different value for each (representing their individual MMRs). When I did that I was able to get a graph that was fairly linear. Now that there's some suggestion the point-to-mmr function is not linear (because why would it be really... the entire Trueskill system works on a basic gaussian distribution function; the core math of trueskill is PDF and CDF functions) this especially makes me wonder what you were doing. Did you just take 7 player's points, assume they had the same mmr (you say that), then add arbitrary point values to each until the curve was linear? If I can add arbitrary values to raw data I can make any function linear. It's still alive so far as people are actively trying to figure the ladder system out. Skeletor and I are working on it daily via the sc2gears plugin and the data we gather from it. Beside that it's hard for me to say who else is actively on the case. You can find us on TL teamspeak quite often. I started out with the assumption that F was linear. We now know that's probably not the case, although it's possible that linear F with slope of 32 is a good approximation. What I did in the part of the OP you're referring to was look at 7 players, assume that for each player, his own MMR didn't change across the data points I looked at. Then because each player has a different MMR, I added a different value to each player's MMR (same value to all of that player's data points) to see if they would fit on a line. Does this prove that F is linear? Clearly not. But to me this strengthened my feeling that it's possible and worth checking, which is what I do in the rest of the OP. On May 17 2012 04:38 celeryman wrote: The second thing I think you were doing, but seemed to be unstated, is using only masters/GM players, because those are the only leagues without division offsets. That seems fine because otherwise the divisions offsets can screw up your calculations. However... if you stick with purely intra-league matchups, you should be able to average out those differences if you can get enough game observations. If you have enough observations, sure. Since at the time I was getting data manually from in game that was not the case. Also, it depends on what you find to achieve. If you want to find the offsets for the different leagues / tiers, then yes you need to look at games below Master as well. However if for start you just want to find F, then players below Master only make things more complicated unnecessarily. On May 17 2012 04:38 celeryman wrote: My final question is a practical one. The bonus pool as well as the data-gathering methods make this process all cumbersome. One issue is if I want to track the last 10 games of a player, I have to work backwards, adding and subtracting points as I go, and I have to make the correct assumptions about the bonus pool as I do it. If you have the exact times available to you, this is possible. But the in-game display system starts to round the times after 24 hours, (i.e. 1 day ago, 1 week ago, 4 weeks ago, 6 weeks ago, etc.). So your bonus pool calculations have got some serious error introduced into them when you get beyond 24 hours. And even if you did take the exact times into account, it takes some fiddling to do the bonus pool calculations too. Did you incorporate those factors into your original calculations? There is something very valuable here, and I think it's possible to get close to what you're talking about, at least on relative terms, but could you re-state your original methodology with a little more precision? I explain why it's in fact not possible to get accurate adjusted points data of a player retroactively at all here. My original methodology is flawed. IF it were possible, it wouldn't make a difference whether the game was played 3 hours ago or 3 weeks ago (beside 3 hours games would be more convenient to backtrack to), so long as you gather all the results in a single point in time they will all share the same total BP (the BP at the time of you taking the results). This is merely technical discussion atm because as I said, you can not infer a player's adjusted points retroactively anyway. The only two ways to collect accurate data are: 1) Do it manually (only practical for your own matches). Write your and your opponent's adj points before the game and points change. If you lost and opponent won, you will most likely have to ask him for his points change without bonus (make sure you ask before leaving the game otherwise chances are he won't even remember by the time you ask him). The only time you can know for certain how many adj points your opponent won is when he has unspent BP left after the match, then you know he got exactly half the points his match history says. 2) Use the sc2gears plugin. It basically automates the first option without having to rely on the opponent to volunteer data. It does it by checking bnet web profile for both players before and after the match, and seeing their adjusted points change. | ||
celeryman
United States54 Posts
One clarification: Then because each player has a different MMR, I added a different value to each player's MMR (same value to all of that player's data points) to see if they would fit on a line. I understand that you took a set offset for each player, and then used that across all their games. I don't think your assumption that MMR doesn't fluctuate between the games you sampled is bad; there's very little bias I could imagine being introduced from that fact (MMRs should fluctuate randomly with the exception that some bias might be upward, but that's a slow, and consistent bias). But how did you determine which player got which offset, and how were the offsets spaced? Bonus pool thought Does the sc2gears plugin back-calculate the bonus pool adjustment? Here's why I ask. If someone's bonus pool is zero, then it's easy, just subtract the total pool from their total points (with the exception of if they ever lost with their points at 0, but even then, small detail). But imagine a player who's on day one (bp at 0) gets 500 points. Almost all of those points will be non-bonus. Then, they don't play a few days (bp at 100). By our standard formula, at this later date they should have 400 adjusted points. But, they actually have 500. This problem will show up for any player who plays with a bonus pool at 0, and then later has an unspent bonus pool. The degree to which it skews the calculations will be a function of the time played while bonus was at 0 (think most high level players), and how large the unspent is. Maybe in practice it's not big and we can ignore it, but when taking the raw data to try and establish the "F" function, the data needs to be only players with BPs at or near 0. I'd like to know if you think, from the data you've seen, that's a common phenomena. | ||
![]()
Excalibur_Z
United States12235 Posts
On May 17 2012 08:47 celeryman wrote: Thank you for your responses. One clarification: Show nested quote + Then because each player has a different MMR, I added a different value to each player's MMR (same value to all of that player's data points) to see if they would fit on a line. I understand that you took a set offset for each player, and then used that across all their games. I don't think your assumption that MMR doesn't fluctuate between the games you sampled is bad; there's very little bias I could imagine being introduced from that fact (MMRs should fluctuate randomly with the exception that some bias might be upward, but that's a slow, and consistent bias). But how did you determine which player got which offset, and how were the offsets spaced? Bonus pool thought Does the sc2gears plugin back-calculate the bonus pool adjustment? Here's why I ask. If someone's bonus pool is zero, then it's easy, just subtract the total pool from their total points (with the exception of if they ever lost with their points at 0, but even then, small detail). But imagine a player who's on day one (bp at 0) gets 500 points. Almost all of those points will be non-bonus. Then, they don't play a few days (bp at 100). By our standard formula, at this later date they should have 400 adjusted points. But, they actually have 500. This problem will show up for any player who plays with a bonus pool at 0, and then later has an unspent bonus pool. The degree to which it skews the calculations will be a function of the time played while bonus was at 0 (think most high level players), and how large the unspent is. Maybe in practice it's not big and we can ignore it, but when taking the raw data to try and establish the "F" function, the data needs to be only players with BPs at or near 0. I'd like to know if you think, from the data you've seen, that's a common phenomena. That's a very good point and emphasizes the importance of pulling information immediately following a game. Even a minor delay of 5 to 10 minutes could mean the difference between a player having 0 or 1 unspent bonus pool and introducing (minor but still statistically significant) inaccuracy. | ||
skeldark
Germany2223 Posts
On May 17 2012 08:47 celeryman wrote: Thank you for your responses. One clarification: Show nested quote + Then because each player has a different MMR, I added a different value to each player's MMR (same value to all of that player's data points) to see if they would fit on a line. I understand that you took a set offset for each player, and then used that across all their games. I don't think your assumption that MMR doesn't fluctuate between the games you sampled is bad; there's very little bias I could imagine being introduced from that fact (MMRs should fluctuate randomly with the exception that some bias might be upward, but that's a slow, and consistent bias). But how did you determine which player got which offset, and how were the offsets spaced? Bonus pool thought Does the sc2gears plugin back-calculate the bonus pool adjustment? Here's why I ask. If someone's bonus pool is zero, then it's easy, just subtract the total pool from their total points (with the exception of if they ever lost with their points at 0, but even then, small detail). But imagine a player who's on day one (bp at 0) gets 500 points. Almost all of those points will be non-bonus. Then, they don't play a few days (bp at 100). By our standard formula, at this later date they should have 400 adjusted points. But, they actually have 500. This problem will show up for any player who plays with a bonus pool at 0, and then later has an unspent bonus pool. The degree to which it skews the calculations will be a function of the time played while bonus was at 0 (think most high level players), and how large the unspent is. Maybe in practice it's not big and we can ignore it, but when taking the raw data to try and establish the "F" function, the data needs to be only players with BPs at or near 0. I'd like to know if you think, from the data you've seen, that's a common phenomena. To find out the adjustment points i do: His points - his unspend unspend points 20 sek after the game is finished - total bonuspool of this sec of the server he play on. So the guy with 500 points have: 500 points +100 unspend -100 total = 500 adjusted To find out first two i can check the webpage. For the total bonuspool i could check a inactive player but thats a very dirty method. Instead i calculate it with the bliz bonuspool algo from the time back the session starts. The session start time i backcaluated depending on the bonuschange +- 5 sec. The bonus pool is calculated with your computer clock and for the case this one is not accurate i backcheck a internet atomic clock. | ||
Not_That
287 Posts
Total server BP is known to increase by 1 every 112 minutes since season start. Once we pin point the minute of season start (we try to get it as close to the exact second as possible, but there's some noise due to funny behavior of bnet website) we should always calculate adjusted points to the exact number, or very rarely be off by 1. | ||
celeryman
United States54 Posts
On May 17 2012 09:12 skeldark wrote: Show nested quote + On May 17 2012 08:47 celeryman wrote: Thank you for your responses. One clarification: Then because each player has a different MMR, I added a different value to each player's MMR (same value to all of that player's data points) to see if they would fit on a line. I understand that you took a set offset for each player, and then used that across all their games. I don't think your assumption that MMR doesn't fluctuate between the games you sampled is bad; there's very little bias I could imagine being introduced from that fact (MMRs should fluctuate randomly with the exception that some bias might be upward, but that's a slow, and consistent bias). But how did you determine which player got which offset, and how were the offsets spaced? Bonus pool thought Does the sc2gears plugin back-calculate the bonus pool adjustment? Here's why I ask. If someone's bonus pool is zero, then it's easy, just subtract the total pool from their total points (with the exception of if they ever lost with their points at 0, but even then, small detail). But imagine a player who's on day one (bp at 0) gets 500 points. Almost all of those points will be non-bonus. Then, they don't play a few days (bp at 100). By our standard formula, at this later date they should have 400 adjusted points. But, they actually have 500. This problem will show up for any player who plays with a bonus pool at 0, and then later has an unspent bonus pool. The degree to which it skews the calculations will be a function of the time played while bonus was at 0 (think most high level players), and how large the unspent is. Maybe in practice it's not big and we can ignore it, but when taking the raw data to try and establish the "F" function, the data needs to be only players with BPs at or near 0. I'd like to know if you think, from the data you've seen, that's a common phenomena. To find out the adjustment points i do: His points - his unspend unspend points 20 sek after the game is finished - total bonuspool of this sec of the server he play on. So the guy with 500 points have: 500 points +100 unspend -100 total = 500 adjusted To find out first two i can check the webpage. For the total bonuspool i could check a inactive player but thats a very dirty method. Instead i calculate it with the bliz bonuspool algo from the time back the session starts. The session start time i backcaluated depending on the bonuschange +- 5 sec. The bonus pool is calculated with your computer clock and for the case this one is not accurate i backcheck a internet atomic clock. The problem is when he then plays the next 100 points off (say wins 100 actual + 100 bonus). Now your formula will have him off by 100. I didn't include that second step because I thought it was implicit. Update: What I wrote in this post is wrong, and about the original adjusted point calculation, but the underlying point remains. See below. | ||
| ||
![]() StarCraft 2 StarCraft: Brood War Dota 2 Counter-Strike Heroes of the Storm Other Games Organizations
StarCraft 2 • davetesta17 StarCraft: Brood War• MJG ![]() • OhrlRock ![]() • AfreecaTV YouTube • intothetv ![]() • Kozan • IndyKCrew ![]() • LaughNgamezSOOP • Migwel ![]() • sooper7s League of Legends Other Games |
Replay Cast
GSL Code S
Classic vs Reynor
GuMiho vs Maru
The PondCast
RSL Revival
GSL Code S
herO vs TBD
TBD vs Cure
OSC
Korean StarCraft League
RSL Revival
SOOP
HeRoMaRinE vs Astrea
Online Event
Clem vs ShoWTimE
herO vs MaxPax
[ Show More ] Sparkling Tuna Cup
WardiTV Invitational
Percival vs TriGGeR
ByuN vs Solar
Clem vs Spirit
MaxPax vs Jumy
RSL Revival
Wardi Open
Monday Night Weeklies
Replay Cast
The PondCast
|
|