Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
It appears that you are using ad block :'(
Hey, we get it. However this website is run by and for the community... and it needs ads in order to keep running.
Please disable your adblock on Smashboards, or go premium to hide all advertisements and this notice. Alternatively, this ad may have just failed to load. Woops!
So you ask a TO to sacrifice the pleasure of his most faithful half of attendees for the placement of the other half which is not even expected to have a good placement to begin with.
Tbh, the less skilled players consider tournaments as a way to make friends that will help them improve. It's not like they can pretend winning money or engraving their performance in Smash history and there's no reason to help them at doing such a thing.
It's a separate competition from all others, not a circuit. If you're seeding to try to make the top 3 look like the top 3 you'd expect, you're cheating people out of fair and fun matches and, more importantly, the ability to improve. A guy in last place won't ever get the chance to play the guy in 2nd to last place, or even the guy halfway up the ladder, because he's playing #1. That's not how a randomized bracket works, and I doubt your pools were randomized for seeding purposes ;p
So you ask a TO to sacrifice the pleasure of his most faithful half of attendees for the placement of the other half which is not even expected to have a good placement to begin with.
Basically what overswarm said but I'd also like to note that context matters too. In a one off event not connected to other events the competition itself shouldn't be influenced by other competitions at all. If the competition is fed in to by another, or if there is an ongoing score kept (like a league) than seeding is totally appropriate.
It doesn't need a poll? I don't think OS posted this with the intent of gathering data in an attempt to force this format into becoming the new standard. Seems to me that he ran this format, got lots of positive feedback, and felt like sharing it with the world. He's not really trying to argue that this is superior in every way, he's saying "It does, in fact, work in a fair and balanced manner, and everyone gets more games to boot."
I did the math for an Apex-sized tournament and got it down to 6-10 hours (depending on the amount of setups), although I was using the assumption that all sets were 15 minutes and didn't account for the world blowing up or other semi-common interferences (edit: this is also assuming that there won't be any setups specifically for friendlies). Here's how it would go:
Start: 400 people
Round 1: 80 pools of 5 (5+4+3+2+1*80), top 2 advance (4 15 minute sets per person going at the same time with 200 setups [enough for each set to have their own TV] = 1 hour, 2 hours with 100, 4 hours with 50)
Post round 1: 160 people
Round 2: 32 pools of 5 (5+4+3+2+1*32), top 2 advance (4 15 minute sets per person going at the same time with 200 or 100 setups [enough for each set to have their own TV] = 1 hour, 2 hours with 50)
Post round 2: 64 people
Round 3: 16 pools of 4 (4+3+2+1*16), top 2 advance (3 15 minute sets per person going at the same time [there should definitely be enough setups by this point] = 45 minutes)
End of round 3: 32 people
Round 4: 8 pools of 4 (4+3+2+1*8), top 2 advance (3 15 minute sets per person going at the same time [there should definitely be enough setups by this point] = 45 minutes)
End of round 4: 16 people
Round 5: 4 pools of 4 people (4+3+2+1*4), top 2 advance (3 15 minute sets per person going at the same time [there should definitely be enough setups by this point] = 45 minutes)
End of round 5: 8 people
Round 6: 2 pools of 4 people (4+3+2+1*2), top 2 advance (3 15 minute sets per person going at the same time [there should definitely be enough setups by this point] = 45 minutes)
End of round 6: 4 people
Finals: 1 pool of 4 people (4+3+2+1), payout based on results (3 15 minute sets per person going at the same time [there should definitely be enough setups by this point] = 45 minutes)
Total time with 200 setups: 60 + 60 + 45 + 45 + 45 + 45 + 45 = 345 minutes (5 hours 45 minutes)
Total time with 100 setups = 120 + 60 + 45 + 45 + 45 + 45 + 45 = 405 minutes (6 hours 45 minutes)
Total time with 50 setups = 240 + 120 + 45 + 45 + 45 + 45 + 45 = 585 minutes (9 hours 45 minutes)
It's possible, although there is some risk involved.
"Anyone who brings a full setup gets a FREE cherry pie! (limit 1 per customer)"
There will be so many setups all up in there that the setups could enter the tournament.
Seriously, though, the 200 setups was assuming the best result, whereas the 50 was assuming the worst. 100 would be the realistic middle. I also made the assumption that, being a larger tourney, there wouldn't be friendlies until there were actually TV's available. Maybe I should've mentioned that.
Round 1: 80 pools of 5 (5+4+3+2+1*80), top 2 advance (4 15 minute sets per person going at the same time with 200 setups [enough for each set to have their own TV] = 1 hour, 2 hours with 100, 4 hours with 50)
This is FAR too big a drop off when you have 0 friendly setups.... and there is no way in hell you'd have that many setups anyway. Killing off half your group is huge but generally necessary, but MORE than half? Ouch.
It's as possible as having infinite setups is, considering I've yet to be at a venue comfortably able to fit in 200 setups and all the players for them.
I never said anything about anyone being comfortable. Only that it was possible. Also I think you missed the part where I said that that was the absolute most that I could possibly factor in.
I fail to see why you bother saying "it's possible" while simultaneously requiring a completely unrealistic # of setups (a number that you agree is, in all likelyhood, not possible). Doesn't the fact that everything you're saying is unrealistic make the idea of an apex sized tourney run with this format also unrealistic? This begs the question
"Why are you posting?"
I think limiting use of this format to smaller, or even midsized events is perfectly acceptable.
Overswarm, I think your method can be improved. Personally, I would start with the number of paid players and work backwards. Mathematically speaking, pools of 4 with top 2 advancing should work the best. Let's look at 66 players, pay out to top 6:
66-MAN (OS-style)
11 pools of 6, top 3 advance: 11*(5+4+3+2+1) = 165 sets, 33 players left.
4 pools of 8 (one has 9), top 4 advance: (3*(7+6+5+4+3+2+1)+1*(8+7+6+5+4+3+2+1)) = 120 sets, 16 players left.
3 pools of 5 (one has 6), top 2 advance: (2*(4+3+2+1)+1*(5+4+3+2+1)) = 35 sets, 6 players left.
1 pool of 6: 5+4+3+2+1 = 15 sets.
TOTAL = 335 sets.
(Yes, I know you were less efficient in order to even things up in terms of seeding, I'm just crunching the plain numbers here)
Now let's look at 66 players, pay out to top 6, and work backwards with my method:
6 players in 1 pool of 6: 5+4+3+2+1 = 6 sets.
This means that the previous round of pools must have started with 6*2 = 12 players, and so on:
12 players in 3 pools of 4, top 2 advance: 3*(3+2+1) = 18 sets, 6 players left.
24 players in 6 pools of 4, top 2 advance: 6*(3+2+1) = 36 sets, 12 players left.
24 is pretty close to 66/2, but we probably don't want to jump from 66 players to 24 players and eliminate 64% of the players in round 1 of pools.
48 players in 12 pools of 4, top 2 advance: 12*(3+2+1) = 72 sets, 24 players left.
(48 is not very close to 66/2, but just work with me here)
Now we find the greatest common factor of 48 and 66, which is 6. That's pitifully small, and 6 pools of 11, top 8 advance would be 330 sets, making round 1 pools take as long as the entire tournament (335 sets, OS-style). Unacceptable!
So we subtract 1 from 66 and find the greatest common factor between 48 and 65, which is 1. That's even worse, 1 pool of 65 (actually has 66 because of the "change"), top 48 advance would be 2211 sets. Hope nobody's in a hurry ...
How about 64 and 48? We're in luck, their greatest common denominator is 16. So now, our entire tournament looks like:
66 players in 16 pools of 4 (two have 5), top 3 advance: (14*(3+2+1)+2*(4+3+2+1)) = 104 sets, 48 players left.
48 players in 12 pools of 4, top 2 advance: 12*(3+2+1) = 72 sets, 24 players left.
24 players in 6 pools of 4, top 2 advance: 6*(3+2+1) = 36 sets, 12 players left.
12 players in 3 pools of 4, top 2 advance: 3*(3+2+1) = 18 sets, 6 players left.
6 players in 1 pool of 6: 5+4+3+2+1 = 15 sets.
TOTAL: 245 sets.
So adding a 5th round of pools lowers the total number of sets significantly. We're also not cutting 50% of the players out in round 1, which should solve a lot of people's issues with it.
Notice that I only have issues with seeding in round 2. In round 2, four pools will have two 1st-seeds, which means those pools will be much harder for the 2nd- and 3rd-seeds. However, we're talking about 8 people out of 48, 17% of the players who made it out of round 1 and only 12% of the total number of players, who according to round 1 probably aren't in the top 16, much less the top 6.
Nobody in the top 6 should get knocked out in round 2. That should only happen if 3 of the top 6 players ended up in the same pool in round 2 (out of 12 pools). It's unlikely that 50% of the top players would end up in 8% of the pools in round 2. Furthermore, we're not putting three 1st-seeds into one pool, so 3 of the top 6 players could only end up in the same pool if one of them wasn't a 1st-seed. That would mean that one of the top 6 got 2nd- or 3rd-seed in round 1, which should only happen if another top 6 player was in their pool. That's 33% of the top players ending up in 6% of the pools in round 1 AND 50% of the top players ending up in 8% of the pools in round 2. You'd pretty much have to manipulate the brackets if you WANTED it to happen.
tl;dr Someone really ought to write a program so that a computer can take care of all this math fast and easy ... In the absence of a program, I'd say the best method of choosing your numbers to minimize the total number of sets and still be fair is: Start from the number of paid players and work backwards, focusing on pools of 4/top 2 advance.
tl;dr Someone really ought to write a program so that a computer can take care of all this math fast and easy ... In the absence of a program, I'd say the best method of choosing your numbers to minimize the total number of sets and still be fair is: Start from the number of paid players and work backwards, focusing on pools of 4/top 2 advance.
Optimization of pools all the way down a final pool of X, given a certain amount of players and certain amount of setups giving all the potential outcomes and how many sets each would have .
Optimization of pools all the way down a final pool of X, given a certain amount of players and certain amount of setups giving all the potential outcomes and how many sets each would have .
int n = total number of players
int x = number of paid players
int y = x
int j = 0
do y = y*2 until y*2 > n this makes y the largest number possible that is smaller than n
it might be worthwhile to have it check if maybe y*2 = n+1 or n+2, so that we would end up with one or two pools with a missing player rather than an extra player
while gcd(y,n-j) < y/4, do j = j+1 gcd stands for "greatest common denominator," although I think these days most people refer to them as "greatest common factors"
the y/4 value is arbitrary, I just made it up on the spot as an example, you'll probably just have to find a good value through trial and error
you might even make an option to let the TOs set the value themselves
number of pools for round 1 = gcd(y,n-j)
number of players per pool for round 1 = n/number of pools
number of players who advance from round 1 = y/number of pools
number of "extra" players = j
I think that about covers it ... I don't think a program like this would throw any errors, but debug it THOROUGHLY, we don't want it crashing at the start of the next big national. You might also consider having it calculate maybe multiple ways of doing round 1 and calculating the total number of sets you'd get for each method so the TO could decide based on time constraints or whatever.
I think that about covers it ... I don't think a program like this would throw any errors, but debug it THOROUGHLY, we don't want it crashing at the start of the next big national. You might also consider having it calculate maybe multiple ways of doing round 1 and calculating the total number of sets you'd get for each method so the TO could decide based on time constraints or whatever.
I did all pools last weekend. Right after the last match of the second to last pool I realized how pointless that match was. It was to determine the 1st and 2nd seed, but every player who advanced past that round goes into the last finals pool. It's not a particularly big problem, but it does annoy me that high seed sets can be completely pointless.
I thought about everyone who enters the final pool with lower than a 1st seed is given one set loss to their overall record. These players can still win by winning all their sets, or get their "correct" placement by 2-0ing everyone expect the players who place higher. But when it comes to trading games and sets these lower seeds will start to be at a disadvantage. The advantage is that it gives meaning to your seed on entering the final pool and you can still win the whole thing. The disadvantage is that the pool idea kind of gives everyone a reset every wave but this introduces unavoidable disadvantages for their placement.
I did all pools last weekend. Right after the last match of the second to last pool I realized how pointless that match was. It was to determine the 1st and 2nd seed, but every player who advanced past that round goes into the last finals pool. It's not a particularly big problem, but it does annoy me that high seed sets can be completely pointless.
I thought about everyone who enters the final pool with lower than a 1st seed is given one set loss to their overall record. These players can still win by winning all their sets, or get their "correct" placement by 2-0ing everyone expect the players who place higher. But when it comes to trading games and sets these lower seeds will start to be at a disadvantage. The advantage is that it gives meaning to your seed on entering the final pool and you can still win the whole thing. The disadvantage is that the pool idea kind of gives everyone a reset every wave but this introduces unavoidable disadvantages for their placement.
Nothing wrong with a reset. Saying a match is "pointless" is ignoring the purpose of playing in the first place; you're meant to improve, get better. If you come into a tournament with M2K, Ally, and Tyrant and DEHF you can probably admit to yourself that you won't make it into top 3, so you won't get money. Given that, exactly zero of your matches matter and you could just leave then and have no change whatsoever to the overall outcome of the day.
BUT
I get what you're saying in that it isn't "exciting". Personally, to me, I don't care. The game itself has excitement and if someone can't play to the best of their ability because they can math out that something isn't on the line, whatever.
Two ways you can fix that:
1) Make people with the best records play other people with the best records. This will result in two 0-0 people playing, then two 1-0 people playing, so on and so forth until one person is ahead of everyone else. Then two 2-1 people can play and that way they're constantly vying for position and it can't be two people playing the bottom dwellers of the pool until they meet up in the end and congratulate each other
2) When determining placement, count up win/loss ratio. Make pools determine placement, then go all the way up to the final pool of 6 or 4 or whatever, then have them play one last round against each other. Then, determine the winners by those 6 players' overall tournament records. Going Ike in pools round 1 could have given them that one loss that breaks them, thus making every match important and exciting. I believe this is a flawed solution as it results in having the same issue (if one guy 2-0'd everyone every match, he'll be near impossible to beat by someone who lost 3 sets throughout the tournament, thus making it not exciting at all) and it hurts people with bad matchups, but it's always an option.
Cool. I actually did one other example that I'll give you as a test number:
37-MAN (FTF-style)
12 pools of 3 (one has 4), top 2 get out: (11*(2+1)+(3+2+1)) = 39 sets, 24 players left.
6 pools of 4, top 2 get out: 6*(3+2+1) = 36 sets, 12 players left.
3 pools of 4, top 2 get out: 3*(3+2+1) = 18 sets, 6 players left.
1 pool of 6: 5+4+3+2+1 = 15 sets.
TOTAL = 108 sets.
Just holler if you need any more test numbers/don't fully understand the method.
Optimization of pools all the way down a final pool of X, given a certain amount of players and certain amount of setups giving all the potential outcomes and how many sets each would have .
I don't think the number of setups matters. I think someone else already mentioned that more setups speeds up the tournament regardless of how you set up pools or brackets. Like, if you have 4 setups for 32 players and have a choice between 4 pools of 8 or 8 pools of 4, you'd still save time by going with the 8 pools of 4 and just assigning two pools per TV (that would also keep people from monopolizing the TVs, because they'd play a set for pool A, then one for pool B, etc. and obviously nobody from pool A plays anybody from pool B).
That said, my method should be the most optimal. The only two methods which are mathematically faster are 2-man pools, top 1 advances or 3-man pools, top 1 advances, but ppl don't like having only top 1 advance. 3-man pools, top 2 advance is a tiny bit slower than 4-man pools, top 2 advance and doesn't work out as well mathematically or in terms of seeding. People will also like it more because pools round 1 will almost never knock out half of the players.
[COLLAPSE="Comparison of 3-2 vs. 4-2"]48 PLAYERS, 4-MAN POOLS, TOP 2 ADVANCE
48 players in 12 pools of 4, top 2 advance: 12*(3+2+1) = 72 sets, 24 players left.
24 players in 6 pools of 4, top 2 advance: 6*(3+2+1) = 36 sets, 12 players left.
12 players in 3 pools of 4, top 2 advance: 3*(3+2+1) = 18 sets, 6 players left.
6 players in 1 pool of 6: 5+4+3+2+1 = 15 sets.
TOTAL: 141 sets.
Compared with
48 PLAYERS, 3-MAN POOLS, TOP 2 ADVANCE
48 players in 18 pools of 3, top 2 advance: 18*(2+1) = 48 sets, 36 players left.
36 players in 12 pools of 3, top 2 advance: 12*(2+1) = 36 sets, 24 players left.
24 players in 8 pools of 3, top 2 advance: 8*(2+1) = 24 sets, 16 players left.
16 players in 5 pools of 3 (one has 4), top 2 advance: (4*(2+1)+(3+2+1)) = 18 sets, 10 players left.
10 players in 3 pools of 3 (one has 4), top 2 advance: (2*(2+1)+(3+2+1)) = 12 sets, 6 players left.
6 players in 1 pool of 6: 5+4+3+2+1 = 15 sets.
TOTAL = 153 sets.
You also end up with uneven seeding all over the place: half of your 3-man pools in any given round will have two 1st-seeds and the other half will have two 2nd-seeds.[/COLLAPSE]
1) Make people with the best records play other people with the best records. This will result in two 0-0 people playing, then two 1-0 people playing, so on and so forth until one person is ahead of everyone else. Then two 2-1 people can play and that way they're constantly vying for position and it can't be two people playing the bottom dwellers of the pool until they meet up in the end and congratulate each other
A tournament match is about judging how good you are. Anything improvement you make mid match would merely be a nice bonus.
The 1st/2nd seed match is pointless because the actual tournament match you play against that person to determine your placement happens in the final pool. Really you should be sand bagging super hard so they aren't given an extra full set to figure you out. You could reverse that and say that the match can be used to learn your opponent, but since he's given the same choices it's better to hold back because you don't know what he's doing.
I don't really see this is a big issue. I just think giving those non-1st seeds a set lose is a decent enough way for people to really play out that match. The loser can still win by beating everyone in the final pool.
I liked it but in the end, for me, a tournament is a tournament. If I hosted again I'd probably do all pools but for attending a tournament it wouldn't really be a selling point that I'd factor in.
Well based off of what he's said (or trying to say) he wants the GCD of the the largest double of y that is < n and n-j(+1?). How he wrote it made it seem like it was a method lol. The rest I'd imagine you understand. If you want some help I could help with the coding because honestly I'm bored, but you're most likely competent enough to do it by yourself.
int n = total number of players
int x = number of paid players
int y = x
int j = 0
do y = y*2 until y*2 > n this makes y the largest number possible that is smaller than n
it might be worthwhile to have it check if maybe y*2 = n+1 or n+2, so that we would end up with one or two pools with a missing player rather than an extra player
while gcd(y,n-j) < y/4, do j = j+1 gcd stands for "greatest common denominator," although I think these days most people refer to them as "greatest common factors"
the y/4 value is arbitrary, I just made it up on the spot as an example, you'll probably just have to find a good value through trial and error
you might even make an option to let the TOs set the value themselves
If you're doubling y until it's greater than n, you'd end up with a number larger than n, rather than the largest possible that's less than n. Unless I'm missing something, you're going to leave the loop with a number larger than n regardless, if you're looking for a number that would be smaller you'd have to have an if statement at the end of the while loop checking to see if the number goes over the value of n, and if it does you break out of the loop.
J would need to have to be declared with a value of 1 would it not? And the while gcd(y,n-j) would need to change to y,n-j+1 because although it'd be used for statistics, because if the gcd is not less than 1/4th the value of y then you will have 0 extra players (assuming extra players would refer to those drowned?).
Well based off of what he's said (or trying to say) he wants the GCD of the number of people paid and the number of people in the tournament. How he wrote it made it seem like it was a method lol. The rest I'd imagine you understand. If you want some help I could help with the coding because honestly I'm bored, but you're most likely competent enough to do it by yourself.
Eh, If I could get going I would probably be like halfway done by now.
EDIT: Forget this. If it would compile(/work) I'd be pretty much set.
That's about where I am at the moment. Now, while I understand what he wants, I have no idea how to do it. I can kinda see what that line of the algorithm wants to do, but I don't fully get it, if that makes any sense.
I understand, I also made some edits after you posted lol. I'm also in highschool with 2 courses of programming so I'm kind of on the same boat as you, but I learned C# and Java. I'm used to just writing in notepad or notepad++. It's actually pretty simple what he wants when you break it down step by step, which he sort of did for us already thankfully. It's kind of just input->calculations->output.
I understand, I also made some edits after you posted lol. I'm also in highschool with 2 courses of programming so I'm kind of on the same boat as you, but I learned C# and Java. I'm used to just writing in notepad or notepad++. It's actually pretty simple what he wants when you break it down step by step, which he sort of did for us already thankfully. It's kind of just input->calculations->output.
Is notepad++ as easy as it looks? If so I'd gladly use it, because it looks like write code > compile (I don't think notepad++ does this, which isn't a big deal) > run. I mean, Visual C++ is giving me all kinds of dumb errors (They hid the compile button, i mean WTF).
So if it's that easy I wouldn't mind using it.
EDIT: I mostly understand what he wants done. I just have no idea what that comma inside the gcd(y,n-j) means. Like, it can't mean divide, add, subtract, or multiply, and I've never seen it before so i have no idea.
It's notepad on steroids really lol. It just highlights things for you, and really is just an easy way to do stuff when you don't have Visual or don't want to use it. Just easier for me and the way I learned it. The comma is just his way of saying that he wants the GCD of those two numbers there, which is the largest number of y (after doubled) that's less than n, and n-j(+1).
It's notepad on steroids really lol. It just highlights things for you, and really is just an easy way to do stuff when you don't have Visual or don't want to use it. Just easier for me and the way I learned it. The comma is just his way of saying that he wants the GCD of those two numbers there, which is the largest number of y (after doubled) that's less than n, and n-j(+1).
I've finished, it's very arbitrary, which is not always the best way to code it, but are there some sort of standard for how many people are paid based off of the amount of entrants? I know some people follow it like for example Top3 regardless, >=40 Top5, >=60 Top 8 etc.
If you use strictly the GCD way you'll possibly end up with a VERY small number of pools for a VERY high number of entrants. For some reason I just added the number of people paid out to the number of pools so it would sort of even itself out, but still that's not the best. Possibly the gcf x2 so it'd be better balanced without having 8 man pools unless that's what you want? The program is done otherwise.
And to find out anything all you really have to do is Google things lol, that's what I do, if I need help with something just Google it, and apply it to what you're doing. Also I don't know what the 4 is for *shrug*
This is correct as long as the number of paid players starts out as less than n/2 (which it honestly should). However, it could perform an erroneous calculation if more than half the players get paid and you used a do-while loop, so a better way would be:
while (y*2 <= n)
{
y = y*2
}
The loop checks at the start if y*2 > n, not if y > n. Since y is the number of paid players, it should start out smaller than n. IF y times 2 is NOT less than or equal to n, which is to say IF y*2 is GREATER than n, then we never enter the loop and we never actually perform the multiplication y = y*2. We stop doubling y BEFORE the act of doubling y would make y exceed n. Therefore, I am correct in how I have worded it: This loop makes y the largest possible value that doesn't exceed n.
The comma means that we are finding the greatest common factor of the two numbers y and (n-j). Since j is initially valued at zero, n-j = n. Thus, we are initially looking for the greatest common factor of y and n.
The reason I divide by 4 is because I personally don't like pools of greater than 4 for mathematical purposes. If you want to divide a bunch of players into pools of 4, you divide the number of players by 4 and discard the remainder. That division operation tells you how many groups of 4 (that is, 4-man pools) you can make from the total number of players. The remainder tells you how many players are not in a pool and have to be added as an "extra" player to an existing pool. For example, 66/4 = 16 remainder 2. That means you have 16 pools of 4 players each and 2 extra players, so you end up with 16 pools of 4 players each, two of which actually have 5 players.
However, computers are not necessarily very good at figuring out remainders, especially when dealing with ints, so I have instead devised a way for us to subtract out the remainder before attempting to divide by 4. That is the purpose of j: to tell us what the remainder is (the computer would ordinarily discard it without telling us) and to subtract it out of the equation so the computer does not have to deal with it.
Here is the best way to find the greatest common factor of two numbers. However, I seriously doubt that it isn't a pre-programmed function in C# (I learned C++, and I'm pretty sure there was a pre-programmed "gcd(x,y)" function in there ... look it up in the cmath library, or whatever they're calling it these days).
Now that I think of it, we don't have to check numbers higher than n to see if they share large common factors with y. If we had 62 players, for example, we could check higher numbers and ultimately find that we could make 16 pools of 4 where two actually have 3. Or we could check lower numbers and ultimately find that we could make 16 pools of 3 where fourteen actually have 4. Both results are identical.
^^And yes, we would want to make 16 pools of 3 where fourteen actually have 4. We do NOT want to make 20 pools of 3 where two actually have 4. Why is that?
So we can use round 1 to narrow down n players to y players. If n = 62 and y = 48, you cannot narrow 62 players down to 48 players with 20 pools.
As I said above, this operation tells us how many pools we need. We have made sure through some clever constraints that we have enough pools so that the number of players per pool does not exceed 4 (except possibly in the case of only a few).
I probably should have written this as (n-j)/number of pools to help people understand it, but because we are dealing with ints, n/number of pools ought to equal (n-j)/number of pools. Why is that?
When dividing ints, the computer automatically discards the remainder. The only difference would be that (n-j)/number of pools subtracts out the remainder before the division, whereas n/number of pools discards the remainder after the division. Either way, the remainder is discarded.
Of course, you have to use your judgement, since this could tell you to make pools of 2 or possibly even pools of 1. You would then have to alter that and instead of (for example) 33 pools of 2, top 1 advances, make it 16 pools of 4 (two actually have 5), top 2 advance, etc. If the computer tells you to make pools of 1 (where possibly a few actually have 2), top 1 advance, then that means you already have close to the perfect number of players and you can just do pools of 4 (where possibly a few actually have 5), top 2 advance until the final round.
The goal of round 1 of pools is to narrow down n players to y players. Because of how we calculated y, once we have y players we can just do pools of 4, top 2 advance until we have the number of paid players left, and then we can put those in a pool for placement.
If we calculate the number of players who advance per pool in this way, then round 1 will narrow us down to y players, which is the goal of round 1.
This tells us the number of players who have to be added to existing pools as "extra" players. In other words, this tells us how many pools out of our however many pools of 4 will actually end up with 5 players.
I understand those as they're, well, simple programming tips, I was just unsure exactly of what some of your variables were representing such as j, where I figured by "extra" you meant players that drowned in each pool. The while statement you made works yeah, but mine does as well, and I was tired and wasn't using my brain completely to do that all in the same statement, johns. Everything else I did seems to be alright for a first stab at it. But it would probably be better for you to make it because you already have the idea in your head, so it's easier for you to enact rather than us assuming things in order to make it work for us.
I already assumed that you had some sort of a CS mathematical background just by the way you structured what you thought the program should be about 2 pages ago. I agree it is pretty simple, but laziness :B
