[Todos] Cambio deadline: Solicitud de problemas para la Regional Latinoamericana del ICPC2013

[Pablo Ariel Heiber]

Enviamos nuevamente el pedido de problemas para la Regional Latinoamericana
ICPC. Debido a un error, la fecha límite de las versiones en español y
portuges del primer envio eran diferentes. Para minimizar los problemas,
la fecha límite para el envio de problemas fue modificada para el dia
16 de junio. Esta es la única modificación en el pedido.


Enviamos novamente a solicitação de problemas para a Regional Latinoamericana
ICPC. Devido a um erro, as datas-limites das versões em português e espanhol
do primeiro envio eram diferentes. Para minimizar os problemas, a data-limite
para envio de problemas foi modificada para o dia 16 de Junho. Este é a única
modificação na solicitação.



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

El Comité de  Problemas de la Regional Latinoamericana  de la ACM ICPC
solicita problemas para su prueba, a tomarse en noviembre de 2013, en
la cual compiten universidades de toda América Latina. El último año
hubo equipos de Argentina, Bolivia, Brasil, Costa Rica, Chile, Colombia,
Cuba, Jamaica, Mexico, Paraguay, Peru, Puerto Rico, Republica Dominicana,
Trinidad y Tobago, Uruguay y Venezuela.

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 16 de junio de 2013:

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


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 por problemas para a Regional Latinoamericana do ICPC2013.
-----------------------

  O Comitê de Problemas da Regional Latino-americana ACM ICPC está
solicitando problemas para a sua prova, que ocorrerá dia novembro
de 2013, na qual competem universidades de toda a América Latina.
No último ano particparam equipes da Argentina, Bolivia, Brasil,
Costa Rica, Chile, Colombia, Cuba, Jamaica, Mexico, Paraguai, Peru,
Puerto Rico, Republica Dominicana, Trinidad-Tobago, Uruguai e Venezuela.

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é 16 de junho de 2013:

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

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 o todo o mês de agosto,
  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).