20/06/2019
Competidores "aposentados" e ex-técnicos da Maratona SBC de Programação.
Considerem submeter problemas para a Regional Sul-Americana do ICPC 2019 (Final da Maratona SBC de Programação). Os problemas que não forem selecionados para a prova (que ocorrerá em Campina Grande, 08-09 de novembro), poderão ser selecionados para a Primeira Fase da Maratona SBC de Programação (realizada em sedes por todo o Brasil, em 14 de setembro).
Confiram a chamada de problemas para mais detalhes.
O Comitê de Problemas da Regional Latino-americana do ICPC
está solicitando problemas para a sua prova, que ocorrerá em
08-09 de novembro de 2019, na qual competem universidades de
toda a América Latina.
Os autores dos problemas selecionados serão convidados a
participar do desenvolvimento final da prova e a participar
como juízes em alguma sede da competição.
Para cada problema, é necessário submeter, até 15 de julho de
2019:
* um arquivo no formato PDF contendo:
- uma descrição precisa do problema, em inglês, com exemplos
de casos de teste (uma história associada não é necessária,
mas é bem-vinda)
- uma descrição das estratégias possíveis para solução; para
problemas em que o tempo de execução seja relevante, indicar
a complexidade máxima aceitável
- um plano de teste simplificado, indicando características
dos te**es que sejam importantes para verificar a corretude
das soluções
- uma estimativa da dificuldade do problema para os
competidores (1 para o problema mais fácil da Regional, 10
para o mais difícil).
Não é estritamente necessário, mas se possível inclua na
submissão:
* uma solução completa, em C, C++, Java, Kotlin ou Python
* um arquivo de te**es que ilustre diferentes cenários, casos
de borda, casos interessantes, etc.
Submissões incompletas ou que não cumpram o formato
estabelecido não serão consideradas. Note, especialmente, que
para facilitar a seleção, toda informação exceto soluções e
arquivos de teste devem ser submetidas em um único arquivo
PDF.
Para submeter um problema envie uma mensagem com os arquivos
descritos para: [email protected]
Restrições:
* o autor não pode ser competidor, técnico (coach) ou diretor
de sede da Regional
* o autor deve ter tempo disponível, durante os meses de
agosto, setembro, e outubro para trabalhar em seu problema
(finalizar e melhorar enunciado, te**es e soluções), e de
preferência ter também tempo para trabalhar em problemas de
outros autores;
* o autor deve se comprometer a manter sigilo sobre o problema
submetido até que o Comitê tenha terminado a seleção dos
problemas, e caso o problema seja selecionado, até o final da
competição.
Os problemas não selecionados podem ser utilizados pelos
autores que os enviaram, em outras competições, ou para
re-envio em outro ano. No caso de autores brasileiros, os
problemas não selecionados podem ser considerados, se o autor
o desejar, para uso na Primeira Fase da Maratona de
Programação, cuja prova ocorrerá no dia 14 de setembro de
2019.
---------------------------------------
Sugestões para escrever um bom problema
---------------------------------------
* Se você nunca escreveu um problema, leia e estude ao menos
uma prova inteira da regional latino-americana de anos
passados antes de começar a escrever. Sugere-se estudar mais
de uma prova.
* Para uma boa prova, necessita-se de problemas de todos os
níveis de dificuldade. Um bom problema não é equivalente a um
problema difícil.
* Há muitos temas para problemas (grafos, programação
dinâmica, geometria, aritmética, guloso, backtracking,
estruturas de dados, etc.). Geralmente grafos e programação
dinâmica são os mais populares, mas os problemas das provas
serão selecionados tendo diversificação em mente. Nota: é
muito bom quando um mesmo problema toca vários temas.
* Procure deixar bem claro quais são as entradas válidas,
incluindo limites para todos os parâmetros.
* Os problemas com saída única são preferíveis. Se sua ideia
tem saída múltipla, há várias técnicas que podem ser usadas
para facilmente transformá-la em um problema com saída única
(resultados em ordem lexicográfica, solicitar apenas o mínimo
e o máximo e não a descrição do conjunto completo de
resultados, etc.).
* Os problemas de decisão são os mais difíceis de testar.
Procure fazer com que as possíveis saídas de seu problema
tenham vários valores (um inteiro, uma cadeia, etc.)
* A menos que a ideia de um problema seja diretamente
relacionada à entrada/saída (por exemplo, problemas de
parsing, ou de desenho na tela), tanto a entrada como a saída
devem ser o mais simples possível de ler usando entrada/saída
padrão (printf/scanf, cout/cin, BufferedReader/System.out).
---
ICPC-LA Problems Committee
[email protected]
Foto da Nicole De Khors do Burst
