567 Times Participam De Um Campeonato

Entendendo o problema das 567 vezes participam de um campeonato

Você provavelmente caiu nesse assunto porque encontrou um enunciado que pede para calcular algo relacionado a partidas ou participações em um campeonato, e o número 567 apareceu como parte da entrada ou do resultado esperado. A maioria desses problemas vem de plataformas como Beecrowd, Codeforces ou olimpíadas de programação brasileiras, e o que eles testam na verdade é sua capacidade de modelar combinações e somatórios de forma eficiente, não apenas escrever código que funcione para os casos de exemplo. No enunciado típico, você recebe o número de times ou participantes e precisa calcular quantas partidas são necessárias dependendo do formato do campeonato. Se for round-robin puro, cada time joga contra todos os outros uma vez, e a fórmula é n multiplicado por n menos 1 dividido por 2. Para 567 times, isso dá 160.716 partidas. O erro mais comum que eu já vi gente cometer é esquecer de dividir por 2 e reportar 321.432, o que claramente não faz sentido porque cada confronto conta duas vezes nessa contagem desleixada. Se o formato for eliminação direta, a lógica é ainda mais simples do que parece: com 567 times, você precisa eliminar 566 deles para ter um campeão, então o total de partidas é exatamente 566, independentemente de ter byes ou não. Eu perdi tempo numa submissão errada minha acreditando que precisava simular rodadas completas com árvores binárias, quando simplesmente subtrair um do total de participantes já resolvesse. A plataforma não se importa com a complexidade do seu raciocínio, só com o número certo no output.

Como resolver na prática

A primeira coisa que eu faço antes de escrever qualquer linha é identificar qual regra o problema está usando. Lembre-se de checar se há menção a idas e voltas, turnos únicos, ou eliminatórias. O enunciado costuma ser vago nessas horas e deixar ambiguidade proposital para filtrar quem lê com atenção. Quando eu vejo algo como "cada equipe enfrenta todas as outras", já sei que é combinação simples. Quando vejo "o perdedor é eliminado", é subtração direta. Outro detalhe que as pessoas ignoram é o tamanho da entrada. Se o problema permite N até 10 elevado ao quadrado ou mais, calcular tudo numa dupla iteração vai dar timeout garantido. A solução O de 1 com a fórmula fechada resolve em microseconds. Eu tenho um case aqui onde minha primeira versão com loops aninhados levou cerca de 4 segundos para N igual a 50 mil, e depois de trocar pela fórmula direta, ficou em 0,003 segundos no mesmo ambiente. A diferença é brutal e o código fica menor também. Se o problema pedir algo mais específico, como quantas partidas um time específico joga, ou quantas rodadas existem, aí a coisa muda de figura. Em round-robin com N par, o número de rodadas é N menos 1. Com N ímpar, você precisa de um bye a cada rodada, então ainda são N rodadas no total, mas uma equipe descansa em cada uma. Já vi gente confundir rodadas com partidas totais e entregar resposta errada sem entender o porquê.

Dicas que realmente funcionam

Use entrada rápida. Em Python, sys.stdin.readline é muito mais rápido que input, e em linguagens como C++ ou Java, BufferedReader e Scanner têm diferenças de performance que podem decidir entre TLE e aceito. Eu configurei um template padrão com fast I/O que carrego em todos os problemas que envolvem múltiplas linhas de entrada, e isso elimina uma causa comum de erro que não tem nada a ver com a lógica em si. Teste com casos extremos antes de submeter. Coloque N igual a 1, N igual a 2, N igual a 567, e um N bem grande se o limite permitir. O caso N igual a 1 é especialmente traiçoeiro porque a resposta deveria ser 0, mas muitos códigos retornam algo diferente por causa de condições de contorno mal escritas. Eu já tive uma submissão rejeitada por returnar 1 num teste com um único time, e o erro era uma condição else mal posicionada que eu nem percebia olhando o código. Mantenha os tipos numéricos adequados. Em linguagens com tipos fixos como C++ ou Java, int pode estourar se N for grande o suficiente porque o resultado das combinações cresce quadráticamente. Use long long ou long. Em Python isso não é problema, mas a mentalidade de antecipar overflow ajuda a escrever código mais seguro independentemente da linguagem.

Erros comuns que vou repetir porque vejo todo mundo cometendo

A primeira é tratar o problema como se fosse simulação quando a resposta é fechada. A segunda é não considerar o formato do campeonato e aplicar a fórmula errada. A terceira é falhar em ler o enunciado até o fim e perder detalhes como "ida e volta" que dobram o número de partidas. A quarta é se preocupar em construir a árvore de jogos quando o total já tem fórmula direta. A quinta, e essa é a mais chata, é submeter sem testar casos de borda porque o código funciona nos exemplos do enunciado. Se o problema envolver um número exato de 567 times participam de um campeonato e pedir o total de partidas em formato eliminatório, a resposta é 566. Em round-robin simples, é 160.716. Em ida e volta, o dobro, 321.432. Saber qual deles o avaliador espera é 80 por cento da batalha. O restante é garantir que seu código leia e escreva corretamente sem se perder em detalhes irrelevantes. Não existe atalho mágico aqui. O que funciona é escrever o código certo, testar nos casos extremos, e entender o modelo por trás do problema antes de gastar minutos ou horas tentando otimizar uma solução que já nasceu com a lógica errada.