2º UTF.c

• Durante a prova:
  • É permitido consultar, e até mesmo copiar, qualquer volume de material impresso ou manuscrito trazido pelos competidores, como livros, cadernos, e apostilas.
  • Não é permitido usar nenhum equipamento eletrônico, nem mesmo celulares ou relógios, exceto a máquina disponibilizada para o time no laboratório.
  • Cada time terá uma única máquina para utilizar, independentemente de o time consistir em 1, 2, ou 3 integrantes. Integrantes de um mesmo time poderão, claro, revezar o uso dessa máquina conforme a estratégia que melhor considerarem.
  • Todas as pessoas integrantes de um time devem ser da mesma instituição e campus, mas não precisam ser necessariamente do mesmo curso.
  • Não é permitido que competidores de times distintos se comuniquem.
  • Se uma pessoa competidora precisar sair do laboratório durante a prova (por exemplo, para ir ao banheiro, ou para comer ou beber alguma coisa), deverá levantar a mão e aguardar o apoio da equipe. Durante esses períodos de curta ausência, essa pessoa não poderá se comunicar com quaisquer pessoas que encontre, a não ser que não pretenda voltar mais ao laboratório.
  • Não é permitido consumir alimentos ou bebidas nos laboratórios.

• A prova consiste num caderno de problemas nos moldes dos problemas da Maratona de Programação, envolvendo conteúdos básicos comuns a disciplinas introdutórias de Computação e alguns pequenos desafios. Você pode consultar a prova do ano passado para ter informações mais concretas sobre o formato.
• Para cada problema, o time deverá desenvolver uma solução em uma das seguintes linguagens permitidas: C, C++, Java, ou Python. O código deverá então ser submetido no local apropriado no sistema, e será julgado por um juiz automático, que avaliará o comportamento do programa para um conjunto de casos de teste secretos. Apesar de cada problema conter exemplos de casos de teste, com os quais os competidores podem testar seus códigos localmente, frisa-se que o conjunto de casos de teste secretos do juiz é geralmente muito maior.
• Toda submissão deve ser uma tentativa legítima de resolver o problema correspondente. Cada submissão pode resultar num dos seguintes vereditos:
  1. NO - COMPILATION ERROR: seu código não foi aceito porque o compilador não conseguiu compilá-lo corretamente;
  2. NO - TIME LIMIT EXCEEDED: seu código não foi aceito porque o programa demorou muito tempo para rodar para algum caso de teste;
  3. NO - RUNTIME ERROR: seu código não foi aceito porque o programa foi abortado pelo sistema operacional por executar alguma operação inválida, como acesso indevido à memória ou exceção de ponto flutuante;
  4. NO - WRONG ANSWER: seu código não foi aceito porque o programa não imprimiu a saída esperada para algum caso de teste;
  5. NO - CLASS NAME MISMATCH (erro exclusivo para códigos submetidos como códigos em Java): seu código não foi aceito porque o nome da classe pública não seguiu o padrão convencionado;
  6. YES: seu código foi aceito e sua equipe ganhou um balão! Parabéns!
• Todos os times que realizarem a prova receberão um certificado de participação. Certificados especiais de reconhecimento serão também entregues:
  • aos três melhores times no placar geral;
  • ao melhor time da UTFPR, caso não tenha sido contemplado no item anterior;
  • ao melhor time composto apenas por mulheres, pessoas transgênero, ou pessoas não-binárias, caso não tenha sido contemplado nos itens anteriores (Prêmio Ada Lovelace do UTF.c);
  • ao melhor time composto apenas por estudantes do Ensino Médio, caso não tenha sido contemplado nos itens anteriores.
• O sistema utilizado nas máquinas da competição será o Maratona Linux, que os estudantes deverão usar para submeter as soluções para os problemas da prova. Para abrir o sistema de submissão dos códigos, basta abrir o navegador no Maratona Linux. Outras páginas da Internet além do sistema de submissão estarão bloqueadas. Qualquer tentativa de tentar violar esse bloqueio acarretará na desclassificação imediata do time.
• Os competidores poderão pedir esclarecimentos sobre os enunciados dos problemas durante a prova apenas através do recurso CLARIFICATIONS, no sistema de submissão. Não serão respondidas perguntas sobre as soluções dos problemas, apenas sobre os enunciados. Perguntas sobre a prova não poderão ser feitas à equipe de apoio.

• Para qualquer par de times \(A, B\) competindo, o time \(A\) ficará à frente do time \(B\) no placar se:
  1. tiver mais balões que o time \(B\);
  2. tiver igual número de balões que o time \(B\), mas pontuação de tempo menor.
• Times com igual número de balões e igual pontuação de tempo são considerados tecnicamente empatados.
• A pontuação de tempo de todos os times começa zerada.
• A competição consiste em 180 minutos de prova, contados a partir de 0. Cada submissão recebe uma timestamp, correspondente ao minuto em que o código foi submetido no sistema (não necessariamente o mesmo minuto em que veio a ser julgado).
• Se a submissão resulta em YES, e se corresponde ao primeiro código aceito que o time conseguiu desenvolver para aquele problema, é somado na pontuação de tempo do time:
  • a timestamp da submissão \(+\) o acumulado de penalidade que o time já tem naquele problema.
• Se a submissão resulta em NO e o time ainda não teve submissão alguma aceita para aquele problema, é acumulado para aquele problema uma penalidade de 20 pontos.
• A penalidade acumulada para um problema só é somada à pontuação de tempo do time quando o time vem de fato a ter uma submissão aceita para aquele problema.

• Para códigos submetidos em C ou C++:
  • Seu programa deve retornar zero, executando, como último comando, return 0 ou exit(0).
  • É sabido que em alguns casos de problemas com entradas muito grandes, os objetos cin podem ser lentos, por conta da sincronização de buffers da biblioteca stdio. Caso deseje utilizar cin e cout, um jeito de se contornar este problema é executando-se o comando ios base::sync_with_stdio(0), no início de sua função main. Note que, neste caso, o uso de scanf e printf no mesmo programa é contra-indicado, uma vez que, com buffers separados, comportamentos inadequados podem ocorrer.
  • Códigos em C serão compilados pelo sistema com: gcc -g -O2 -std=gnu11 -static -lm
  • Códigos em C++ serão compilados pelo sistema com: g++ -g -O2 -std=gnu++20 -static
  • É recomendável compilar localmente seu código com as flags acima especificadas para garantir que sua submissão não resultará em NO - COMPILATION ERROR.
• Para códigos submetidos em Java:
  • O nome do arquivo deverá corresponder à letra do problema. Exemplo: A.java, B.java, C.java etc.

  • O nome da classe pública do código deve ser uma letra maiúscula, também correspondente à letra do problema (A, B, C etc.). Isto é, por exemplo, use

    public class A {
      public static void main(String[] args) throws IOException {
        // code
      }
    }
    

    ao invés de

    public class Main {
      public static void main(String[] args) throws IOException {
        // code
      }
    }
    

  • O código será compilado com javac.
• Para códigos submetidos em Python:
  • Apenas Python 3 é suportado.
  • Não há a garantia de que códigos submetidos em Python passarão dentro do limite de tempo especificado para cada problema.

• Submeta apenas o código-fonte de seu programa! Não submeta o arquivo executável!

• Os códigos são avaliados de modo automático. Portanto, siga rigorosamente os formatos da entrada e da saída especificados nos enunciados dos problemas, conforme os exemplos fornecidos no caderno de prova. Por exemplo, se o problema pede para seu programa ler um inteiro positivo \(N < 100\) e imprimir o quadrado de \(N\), uma possível solução em C seria:

  #include<stdio.h>
  
  int main(void) {
    int n;
    scanf("%d", &n);
    printf("%d\n", n * n);
  }
  

  • Não imprima nada além do valor esperado! Por exemplo, NÃO inclua no seu código coisas como printf("Digite o numero: ");
  • Os elaboradores da prova garantem que seu programa só será testado com entradas que satisfazem as restrições do enunciado. Se o enunciado garante que o valor \(N\) da entrada é um inteiro positivo menor que \(100\), você pode confiar nessa garantia, não sendo necessário testá-la, nem validá-la.
• Se você é iniciante no mundo da Programação Competitiva, recomendamos a Jornada de Iniciação do Clube de Programação

• Prof. Leandro Zatesko (DAINF/UTFPR-CT)
• Fernando Kiotheka (UFPR)
• Thaís Carvalho (UTFPR-CT)
• Alan Tara (UTFPR-CT)
• Henrique Mendes (UTFPR-CT)

• Prof. Leandro Zatesko (DAINF/UTFPR-CT)
• Profª. Marina Esther Groshaus (DAINF/UTFPR-CT)
• Alan Tara (UTFPR-CT)
• Eduardo Moreira (UDESC)
• Enzo Rodrigues (UDESC)
• Eric Grochowicz (UDESC)
• Fernando Kiotheka (UFPR)
• Gabriel Conke (UTFPR-CT)
• Henrique Bubniak (UTFPR-CT)
• Henrique Mendes (UTFPR-CT)
• Henrique Zambenedetti (UTFPR-CT)
• João Oliveira (UDESC)
• Pedro Vinicius Silva (UFPR)
• Thaís Carvalho (UTFPR-CT)
• Tália Aguiar (UTFPR-CT)
• Thiago Mendonça (UTFPR-CT)
• Vinicius Tikara (UFPR)

Please note that being well-versed in competitive programming is not the end goal, but only a means to an end. The true end goal is to produce all-rounder computer scientists/programmers who are much readier to produce better software and to face harder CS research problems in the future.

— Steve & Felix Halim, Competitive Programming Book