[Todos] Recordatorio: Solicitud de problemas para la Regional Latinoamericana del ICPC2015

[Alejandro Strejilevich de Loma]

Hola.  Quedan poco más de dos semanas para los que quieran enviar 
problemas.  Saludos.

-----
Alejandro Strejilevich de Loma
asdel en dc.uba.ar
67,5% de capacidad para la docencia según Expediente 501319/12

-------- Mensaje original --------
Asunto: Solicitud de problemas para la Regional Latinoamericana del 
ICPC2015
Fecha: 2015-04-13 18:21
Remitente: Ricardo Anido

-------------------------------------------------------
Solicitud de problemas para la Regional Latinoamericana del ICPC2015
-------------------------------------------------------

El Comité de Problemas de la Regional Latinoamericana de la ACM ICPC
solicita problemas para su prueba, a tomarse en noviembre de 2015, 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 14 de junio de 2015:

* 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 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).

-------------------------------------------------------
Chamada de Problemas para a Regional Sul-Americana do ICPC2015
(Final da Maratona de Programação da SBC)
-------------------------------------------------------

O Comitê de Problemas da Regional Latino-americana ACM ICPC está
solicitando problemas para a sua prova, que ocorrerá em novembro de
2015, 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é 14 de junho de 2015:

* 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. No
caso de autores brasileiros, os problemas não selecionados podem ser
ser considerados, se o autor o desejar, para uso na Primeira Fase da
Maratona de Programação, cuja prova ocorrerá no dia 12 de setembro de
2015.

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).

---
Ricardo Anido
IC-UNICAMP
Av. Albert Einstein, 1251
13083-852 Campinas SP
Tel. (19) 3521 5863    Fax. (19) 3521 5847