Sete de maio, terça-feira, aconteceu a Rinha de Calouros de 2024. A competição era em equipes de até três pessoas, mas eu participei sozinho porque meus amigos, que tem mais juízo do que eu, preferiram ficar estudando para a prova de Cálculo I que teríamos na sexta.

Cheguei no evento bem triste, bem desanimado, não só porque estava sozinho, mas também porque tinha tido uma séria de problemas pessoais e parecia que tudo estava dando errado pra mim naquela semana. Eu estava muito ansioso no início da prova, o que sempre me torna menos eficiente. Quando acabei de codar meu template (que era bem básico), um dos problemas já havia sido resolvido. Isso funcionou a meu favor pois, sozinho, minha estratégia era: ao invés de procurar as questões mais fáceis por mim mesmo, eu simplesmente fiquei de olho no placar e, cada vez que um time resolvia um problema, eu ia atrás e fazia o mesmo problema. Assim, consegui três dos sete possíveis balões, o que me rendeu a segunda colocação no ranking final.

Por muito pouco, quase nada, não passei outros dois problemas. Cheguei na “solução” para os problemas A e C, mas errei na escrita do código. Acho que essa foi a hora em que mais senti falta de ter alguém com quem discutir as questões durante a prova, se eu tivesse simplesmente explicado meu código em voz alta para alguém, acredito que eu teria percebido meus erros. Felizmente, no final de semana seguinte, fui introduzido ao conceito de “rubber duck debugging” e, agora, levo sempre comigo um astronauta de brinquedo. Então estou confiante de que essa situação não há de se repetir.

A premiação para o segundo lugar eram três lanches no Kelson (presumivelmente, um para cada membro de um trio), enquanto a premiação para o primeiro lugar eram seis lanches (dois para cada um). Mas, como o primeiro lugar estava em três pessoas e eu estava sozinho, ainda acabei com o maior prêmio “per capito”.

Essa competição foi muito legal. Eu cheguei triste e sozinho e saí feliz e cercado de amigos. Certamente valeu a nota baixa que está por vir em Cálculo.

No dia 15, durante a Semana da Computação da Udesc, o Brute organizou um evento de coding game. Eu nunca tinha ouvido falar desse negócio. Funciona assim: existem três categorias, quem resolve o problema mais rapidamente, que o faz com o menor número de caracteres e “reverse”, na qual os jogadores têm que adivinhar o que a questão pede só com base nos exemplos. No final de cada rodada, os jogadores com pior desempenho são eliminados.

Ao aprender as regras, eu, que digito muito devagar e uso nomes longos para funções e variáveis, já sabia que não iria muito longe. E, quando anunciaram como seria a final, com os dois últimos competidores sentados frente a frente, rodeados pelas outras pessoas, disputando uma melhor de três com rodadas de cinco minutos, eu fiquei até aliviado de saber que seria eliminado antes de chegar a isso, mas eu ainda estava disposto a me esforçar pra ver até onde eu iria.

Pois bem, não é que eu cheguei na final? Aqui não tem surpresa porque já está no título do post, acabei em segundo lugar. Eu estava tão nervoso na hora que não consegui digitar nada pelos primeiros três minutos da primeira rodada e, na segunda, pensei na resposta certa, mas escrevi errado… Eu fico pensando que eu digito devagar e que escrevo demais, mas, na verdade, meu maior ponto fraco é o nervosismo. Minhas mãos ainda tremiam depois do fim da premiação. Ganhei um botton bonitinho com o mascote do Brute.

Esse é um dos motivos pelos quais eu mais gosto de programação competitiva, independentemente de desempenho, eu sempre acabo me sentido bem. O Brute tem uma cultura interna muito legal, todo mundo se ajuda e apoia em tudo.

No mesmo dia do coding game, o Brute também trouxe o Ber da Unicamp para dar uma palestra (na qual eu dei mole e não tirei foto). Ele falou sobre binary lifting, que eu não conhecia, e mostrou a aplicação disso em algumas questões. Eu ainda não estou no nível de pegar tudo o que ele passou, mas a experiência certamente agregou bastante. O cara, além de bom, é muito gente fina.

Nessa sexta (26/04), participamos da nossa primeira competição fora de casa: a Stairway to Deven, da UFSC. Foi um evento caótico, mas nos saímos bem – ainda que tenhamos perdido uma questão por não saber imprimir um float com dois pontos de precisão usando cout (emoji de caveirinha).

Nesse dia, Jota nos surpreendeu com um presente incrível: bottons com nossa logo, um Lambda com marca de batom. Atrás de nós, a faixa anunciando a greve dos servidores Técnico-administrativos em Educação (TAEs).

Era uma competição de calouros e, para isso, a UDESC mandou quatro times que competiram além dos veteranos do Brute que foram nos dar apoio (e carona de volta para a universidade).

O evento em si foi um caos completo, começando pelo local e hora da prova: nas escadas do hall da UFSC ao meio-dia. Sim, o local da prova era uma escadaria e ela aconteceu em um momento de alta circulação de estudantes. Além disso, organização do evento disponibilizou apenas uma cadeira para cada equipe de três pessoas, mas esclareceu que “os demais participantes podem sentar nas escadas ou ficar por aí para discutir as soluções”. Achei inusitado. Para completar, se não bastasse estarmos em um local barulhento e movimentado, a prova ainda envolvia uma banda tocando ao vivo, um verdadeiro teste de foco e concentração.

Quanto às questões, eram cinco, das quais duas estavam erradas.

A) Dados dois números, c e n, perguntava o que era maior, c^n ou n!. Como c e n poderiam ser números até 10^9, não é possível calcular c^n e n! para comparar os resultados. Sabendo disso, eu inferi que deveria haver alguma regra que poderia ser usada para identificar qual era maior sem ter que fazer as contas. Então comecei a jogar números na calculadora para ver se encontrava algum padrão. Cheguei na hipótese de que se n > 2c, n! > c^n. Codei essa solução e fomos a única equipe a passar essa questão. Aparentemente, esse meu processo de jogar números na calculadora até chegar num padrão foi o que quem criou o problema fez porque nós dois chegamos na mesma solução errada. Como bem notado pelo eemo, existem casos em que essa regra falha. Um exemplo que ele encontrou é para c = 10 e n = 22. Nesse caso, n é maior que 2c, mas c^n > n!.

B) Provavelmente a mais difícil da prova. Eu acho que conseguiríamos resolvê-la, mas não tivemos tempo nem de começar a tentar.

C) A segunda mais fácil da prova, envolvia descobrir a área de um círculo circunscrito em um quadrado. Assim que lemos o enunciado, o Jota ficou encarregado de fazer as contas para chegar na resposta enquanto o Rian e eu tentávamos, cada um de um jeito, encontrar a solução para o problema A. Quando o Jota acabou as contas, exclamou “Não faz sentido, a área do círculo tá dando maior do que a área do quadrado!”. Ele estava usando a fórmula do comprimento da circunferência para calcular a área do círculo… Depois de perceber o engano e usar a fórmula certa, escrevemos o código com a solução que ele encontrou faltando 6 segundos para o fim da prova. Mas ainda tínhamos um problema: nós não sabíamos como imprimir um float com duas casas de precisão usando cout (o que era exigido pela questão)… Trocamos o cout por printf, mas era tarde demais. Fizemos a questão, chegamos na solução correta, mas não conseguimos enviar o código. Isso nos custou, no mínimo, o terceiro lugar. Acabamos em sexto.

D) Era a mais fácil, basicamente, bastava contar quantas vezes uma letra aparecia em uma string. Quase todo mundo fez essa.

E) Essa questão foi anulada assim que o contest começou pois ela estava com problema.

Ou seja, duas das cinco questões da prova estavam erradas. A cereja do bolo é que a prova foi realizada no beecrowd (fato que provavelmente fala por si mesmo). Essas duas coisas, juntas, somaram ao clima caótico do dia.

Na foto, eu, jogando números na calculadora tentando encontrar um padrão para a questão A, Rian, tentando lembrar como fazia fatorial recursivo e Jota, focado usando a fórmula da circunferência para encontrar a área do círculo.

Cometemos alguns erros, é verdade, acho que poderíamos ter conseguido uma colocação melhor. Mas eu estou muito contente com o nosso resultado e, principalmente, com a forma como nós nos dividimos para fazer as tarefas. No blog anterior, eu contei sobre um desempenho ruim que tínhamos tido em função de, o que concluí como, falta de organização. Nós conversamos sobre isso e nos propusemos a experimentar fazer essa prova de um jeito diferente e funcionou! Saí bastante satisfeito – ainda que um pouco frustrado por não ter tido tempo de enviar aquela última questão.

Na foto, as equipes “Tu computas” e “Programação Funcional e Beijo na Boca”.

Quando ficamos sabendo que não haveriam cadeiras para todo mundo e que a prova aconteceria numa escadaria, o Rian quis desistir de ir para ficar na UDESC e participar de forma online, mas eu insisti para que fossemos mesmo assim – e acho que foi uma boa. Eu penso mesmo que tudo passa muito rápido, o que fica (quando fica) são as memórias. E é por isso que escrevo esse blog, porque sei que em alguns, breves, anos mesmo os acontecimentos mais ordinários terão se forjado em preciosos vislumbres de uma outra vida. Em pouquíssimo tempo, as fotos de ontem serão portadoras de uma entorpecente nostalgia. Penso que passar perrengue por uma hora é um preço pequeno a pagar para poder contar a história da vez em que participamos de um contest na escada.

Agradeço a companhia dos amigos, fui muito feliz no caos da escadaria do hall da UFSC.

Depois de um resultado triunfante na semana passada, o contest de ontem (23/04) veio como um choque de realidade: resolvemos apenas um dos sete problemas.

Não sei o que aconteceu. Até chegamos a codar a resposta para outros três problemas – e acredito que tenhamos chegado na solução adequada para cada um deles –, mas falhamos em fazer esses códigos funcionarem.

Estávamos desorganizados. Nos equivocamos na interpretação das questões. Perdemos muito tempo com erros básicos de lógica. Para dar um exemplo, houve um momento em que eu escrevi o código para uma questão que eu não tinha nem lido, apenas com base no que o Jota tinha me explicado, só para chegar na hora de rodar o programa e descobrir que o que tínhamos feito não era o que havia sido pedido. Em outra ocasião, me vi ditando o código de um problema para o Rian escrever. É óbvio que isso é ruim e ineficiente. É fácil perceber esse fato retroativamente, mas, na hora, no calor do momento – calor literal porque a sala não tinha ar condicionado e o suor escorria pela minha nuca –, é difícil perceber e, principalmente, corrigir essas coisas.

Em conclusão, nos faltou coordenação, organização e um método adequado de leitura das questões. Felizmente, quanto a esse último item, parece que a questão F, Otimizando Leitura, oferece uma luz – aplicaremos a estratégia nela descrita na próxima vez.

Apesar de todos os pesares, fico feliz. Continua sendo uma experiência positiva. Afinal, é pra isso que essas competições servem, para que a gente possa treinar as habilidades que nos faltam. E, com sorte, vou ficando menos ansioso a cada competição.

Não adianta lamentar. Agora o que resta é fazer o upsolve das questões durante a semana porque sexta-feira tem mais!

PS: Para completar a tempestade de infortúnios, o CF ainda ficou fora do ar por mais de uma hora durante a prova, então não podíamos testar os códigos...

Em 15 de abril de 2024, Jota, Rian e eu criamos nosso primeiro time de programação competitiva: o Programação Funcional e Beijo na Boca. A ideia de formar um time já existia desde o semestre passado, quando ingressamos no curso de Ciência da Computação na UDESC e começamos a participar da Brute Class, aulas de programação competitiva para calouros (acho que nenhum de nós nunca tinha nem ouvido falar de programação competitiva antes disso, mas só posso afirmar por mim), porém ainda não havia tomado forma.

No dia seguinte, tivemos nossa primeira prova: Maratonando — day 3. Conseguimos resolver 4 das 7 questões durante as, pouco menos de, duas horas de prova. Isso nos rendeu a quinta posição no geral e a primeira colocação entre os calouros.

Acho que podíamos ainda ter resolvido as questões F (que era até mais fácil do que outras que fizemos) e D (que o Jota, corretamente, identificou como sendo uma busca binária), mas não deu tempo. O tempo que faltou para fazer a F foi perdido com a C: chegamos na solução dela rapidamente, mas criamos um array com tamanho errado e levamos – o que pareceram – séculos para encontrar o problema.

Fiquei muito feliz com o nosso resultado. Eu não conseguia parar de sorrir ao fim do contest. Eu já havia participado, sozinho, de outras provas parecidas nas semanas anteriores (Maratonando day 1 e day 2), mas estar com amigos é completamente diferente, é muito melhor. A felicidade só é real quando é compartilhada.

Agradeço muito a todos do Brute e aos meus amigos jota_zacheo e Rian2601. Esse é só o começo!

(Primeira fanart que recebemos: Jota fazendo a parte da programação funcional, Rian e eu fazendo a parte do beijo na boca)