[Todos] Solicitud de problemas para la Regional Latinoamericana del ICPC2014

[Pablo Ariel Heiber]

Ultimos 3 dias para enviar propuestas!

2014-03-20 19:19 GMT-03:00 Pablo Ariel Heiber <pheiber en dc.uba.ar>:
> (favor de difundir)
>
> Solicitud de problemas para la Regional Latinoamericana del ICPC2014
> -----------------------
>
> El Comité de  Problemas de la Regional Latinoamericana  de la ACM ICPC
> solicita problemas para su prueba, a tomarse en noviembre de 2014, en
> la cual compiten universidades de toda América Latina.
>
> Los  autores   de  los  problemas  seleccionados   serán  invitados  a
> participar del desarrollo  final de la prueba regional  y a participar
> como jueces en algún sitio de competencia.
>
> Para cada problema, es necesario enviar, hasta el 23 de mayo de 2014:
>
> * un archivo en formato PDF conteniendo:
>
>   - una  descripción precisa del problema, en idioma inglés, con ejemplos de
>    casos de test (es bienvenida pero no es necesaria la historia de fondo)
>
>   - una  descripción  de  las estrategias  posibles de  solución; para
>    problemas en los que el  tiempo de ejecución es relevante, indicar
>    la complejidad máxima aceptable
>
>   - un  plan de  tests simplificado, indicando características  de los
>    tests que  sean importantes para  verificar la correctitud  de las
>    soluciones
>
>   - una estimación de la dificultad del problema para los competidores
>    (1  para el  problema mas  fácil de  la Regional,  10 para  el más
>    difícil).
>
> * una solución completa, en C, C++ o Java
>
> * un  archivo de  tests que  ilustre diferentes  escenarios,  casos de
>  borde, casos interesantes, etc.
>
> Se rechazarán los envios incompletos o que no cumplan el formato
> establecido. Notar especialmente que toda la información excepto
> archivos de entrada/salida y códigos fuente debe ir en un mismo PDF.
>
> Para  enviar un  problema, enviar  un mail  a problem.setter en gmail.com
> para recibir información sobre como proceder.
>
> Restricciones:
>
> * El autor  no puede ser competidor,  coach ni director de  sede en la
>   Regional
>
> * El autor debe tener tiempo  disponible durante los meses de julio, agosto
>   y septiembre  para  trabajar  en  su  problema  (finalizar  y  mejorar
>   enunciado, soluciones  alternativas, creación  de los casos  de test
>   finales), y de preferencia también tiempo para trabajar en problemas
>   de otros autores
>
> * El  autor se  debe compremeter  a  mantener en  secreto el  problema
>   enviado hasta que el Comité termine la selección de problemas, y en caso de
>   ser seleccionado, hasta luego de finalizar la competencia.
>
> Los problemas  no seleccionados podrán ser utilizados  por los autores
> que los enviaron para otras competencias, o para enviar otro año.
>
> --------------------------------------------
> Sugerencias para escribir un buen problema
> ------------------------------------------
>
> * Si nunca lo ha hecho, lea al menos una prueba pasada latinoamericana
>   entera antes de empezar a escribir. Es sugerido leer más de una. Por
>   leer  queremos   decir  entender  la  idea  de   cada  problema,  no
>   simplemente mirar las letras.
>
> * Hacen falta problemas de todas las dificultades. Buen problema no es
>   equivalente a problema difícil.
>
> * Hay  muchos  temas para  problemas  (grafos, programación  dinámica,
>   geometría, aritmética,  goloso, backtracking, estructuras  de datos,
>   etc). Generalmente grafos y programación dinámica suelen ser los más
>   populares    y    la    prueba    será    seleccionada    intentando
>   diversificar. Nota: Está bien que un problema toque varios temas.
>
> * Conviene  dejar   bien  claro  cuáles  son   las  entradas  válidas,
>   incluyendo límites para todos los parámetros.
>
> * Los  problemas   con  salida  única   por  caso  de  test   son  muy
>   preferibles.  Si  una idea tuviera  una salida múltiple  posible, hay
>   varias técnicas  que se pueden  usar para volverla  única fácilmente
>   (lexicográficamente  menor,  pedir sólo  el  mínimo/máximo  y no  la
>   descripción de cómo se llega a él, etc).
>
> * Los problemas de decisión son  más difíciles de testear. Intente que
>   la salidas posibles de su problema tengan varios valores (un entero,
>   una cadena, etc).
>
> * Salvo que  la idea  del problema sea  directamente relacionada  a la
>   entrada/salida  (por ejemplo, problemas  de parsing  o de  dibujo en
>   pantalla),  tanto  entrada como  salida  deben  ser  lo más  simples
>   posibles  para leer  usando los  mecanismos  estándar (scanf/printf,
>   cin/cout, BufferedReader/System.out.println).
>
> ----
>
> O Comitê de Problemas da Regional Latino-americana ACM ICPC está
> solicitando problemas para a sua prova, que ocorrerá dia novembro
> de 2014, 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é 23 de maio de 2014:
>
> * 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 é
>     benvinda)
>
>   - 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
>     testes 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).
>
> * uma solução completa, em C, C++ ou Java
>
> * um arquivo de testes 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, contacte problem.setter en gmail.com para
> receber informações sobre como proceder.
>
> 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 julho, agosto,
>   e setembro para para trabalhar em seu problema (finalizar e melhorar
>   enunciado, testes 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.
>
> 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 garfos 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).