<div dir="ltr"><div class="gmail_quote"><div>(favor de difundir)</div><div dir="ltr"><br></div><div dir="ltr">-------------------------------------------------------<br>Solicitud de problemas para la Regional Latinoamericana del ICPC2015<br>-------------------------------------------------------<br><br>El Comité de Problemas de la Regional Latinoamericana de la ACM ICPC<br>solicita problemas para su prueba, a tomarse en noviembre de 2015, en<br>la cual compiten universidades de toda América Latina.<br><br>Los autores de los problemas seleccionados serán invitados a<br>participar del desarrollo final de la prueba regional y a participar<br>como jueces en algún sitio de competencia.<br><br>Para cada problema, es necesario enviar, hasta el 14 de junio de 2015:<br><br>* un archivo en formato PDF conteniendo:<br><br>  - una descripción precisa del problema, en idioma inglés, con<br>   ejemplos de casos de test (es bienvenida pero no es necesaria la<br>   historia de fondo)<br><br>  - una descripción de las estrategias posibles de solución; para<br>   problemas en los que el tiempo de ejecución es relevante, indicar<br>   la complejidad máxima aceptable<br><br>  - un plan de tests simplificado, indicando características de los<br>   tests que sean importantes para verificar la correctitud de las<br>   soluciones<br><br>  - una estimación de la dificultad del problema para los competidores<br>   (1 para el problema mas fácil de la Regional, 10 para el más<br>   difícil).<br><br>* una solución completa, en C, C++ o Java<br><br>* un archivo de tests que ilustre diferentes escenarios, casos de<br> borde, casos interesantes, etc.<br><br>Se rechazarán los envios que no cumplan el formato establecido. Notar<br>especialmente que toda la información excepto archivos de<br>entrada/salida y códigos fuente debe ir en un mismo PDF.<br><br>Para enviar un problema, enviar un mail a <a href="mailto:problem.setter@gmail.com" target="_blank">problem.setter@gmail.com</a><br>para recibir información sobre como proceder.<br><br>Restricciones:<br><br>* El autor no puede ser competidor, coach ni director de sede en la<br>  Regional<br><br>* El autor debe tener tiempo disponible durante los meses de julio,<br>  agosto y septiembre para trabajar en su problema (finalizar y<br>  mejorar enunciado, soluciones alternativas, creación de los casos de<br>  test finales), y de preferencia también tiempo para trabajar en<br>  problemas de otros autores<br><br>* El autor se debe compremeter a mantener en secreto el problema<br>  enviado hasta que el Comité termine la selección de problemas, y en<br>  caso de ser seleccionado, hasta luego de finalizar la competencia.<br><br>Los problemas no seleccionados podrán ser utilizados por los autores<br>que los enviaron para otras competencias, o para enviar otro año.<br><br>-------------------------------------------<br> Sugerencias para escribir un buen problema<br>-------------------------------------------<br><br>* Si nunca lo ha hecho, lea al menos una prueba pasada latinoamericana<br>  entera antes de empezar a escribir. Es sugerido leer más de una. Por<br>  leer queremos decir entender la idea de cada problema, no<br>  simplemente mirar las letras.<br><br>* Hacen falta problemas de todas las dificultades. Buen problema no es<br>  equivalente a problema difícil.<br><br>* Hay muchos temas para problemas (grafos, programación dinámica,<br>  geometría, aritmética, goloso, backtracking, estructuras de datos,<br>  etc). Generalmente grafos y programación dinámica suelen ser los más<br>  populares y la prueba será seleccionada intentando<br>  diversificar. Nota: Está bien que un problema toque varios temas.<br><br>* Conviene dejar bien claro cuáles son las entradas válidas,<br>  incluyendo límites para todos los parámetros.<br><br>* Los problemas con salida única por caso de test son muy preferibles.<br>  Si una idea tuviera una salida múltiple posible, hay varias técnicas<br>  que se pueden usar para volverla única fácilmente<br>  (lexicográficamente menor, pedir sólo el mínimo/máximo y no la<br>  descripción de cómo se llega a él, etc).<br><br>* Los problemas de decisión son más difíciles de testear. Intente que<br>  la salidas posibles de su problema tengan varios valores (un entero,<br>  una cadena, etc).<br><br>* Salvo que la idea del problema sea directamente relacionada a la<br>  entrada/salida (por ejemplo, problemas de parsing o de dibujo en<br>  pantalla), tanto entrada como salida deben ser lo más simples<br>  posibles para leer usando los mecanismos estándar (scanf/printf,<br>  cin/cout, BufferedReader/System.out.println).<br><br><br>-------------------------------------------------------<br>Chamada de Problemas para a Regional Sul-Americana do ICPC2015<br>(Final da Maratona de Programação da SBC)<br>-------------------------------------------------------<br><br>O Comitê de Problemas da Regional Latino-americana ACM ICPC está<br>solicitando problemas para a sua prova, que ocorrerá em novembro de<br>2015, na qual competem universidades de toda a América Latina.<br><br>Os autores dos problemas selecionados serão convidados a participar do<br>desenvolvimento final da prova e a participar como juízes em alguma<br>sede da competição.<br><br>Para cada problema, é necessário submeter, até 14 de junho de 2015:<br><br>* um arquivo no formato PDF contendo:<br><br>  - uma descrição precisa do problema, em inglês, com exemplos de<br>    casos de teste (uma história associada não é necessária, mas é<br>    benvinda)<br><br>  - uma descrição das estratégias possíveis para solução; para<br>    problemas em que o tempo de execução seja relevante, indicar a<br>    complexidade máxima aceitável<br><br>  - um plano de teste simplificado, indicando características dos<br>    testes que sejam importantes para verificar a corretude das<br>    soluções<br><br>  - uma estimativa da dificuldade do problema para os competidores (1<br>    para o problema mais fácil da Regional, 10 para o mais difícil).<br><br>* uma solução completa, em C, C++ ou Java<br><br>* um arquivo de testes que ilustre diferentes cenários, casos de<br>  borda, casos interessantes, etc.<br><br>Submissões incompletas ou que não cumpram o formato estabelecido não<br>serão consideradas. Note, especialmente, que para facilitar a seleção,<br>toda informação exceto soluções e arquivos de teste devem ser<br>submetidas em um único arquivo PDF.<br><br>Para submeter um problema, contacte <a href="mailto:problem.setter@gmail.com" target="_blank">problem.setter@gmail.com</a> para<br>receber informações sobre como proceder.<br><br>Restrições:<br><br>* o autor não pode ser competidor, técnico (coach) ou diretor de sede<br>  da Regional<br><br>* o autor deve ter tempo disponível, durante os meses de julho,<br>  agosto, e setembro para para trabalhar em seu problema (finalizar e<br>  melhorar enunciado, testes e soluções), e de preferência ter também<br>  tempo para trabalhar em problemas de outros autores;<br><br>* o autor deve se comprometer a manter sigilo sobre o problema<br>  submetido até que o Comitê tenha terminado a seleção dos problemas,<br>  e caso o problema seja selecionado, até o final da competição.<br><br>Os problemas não selecionados podem ser utilizados pelos autores que<br>os enviaram, em outras competições, ou para re-envio em outro ano. No<br>caso de autores brasileiros, os problemas não selecionados podem ser<br>ser considerados, se o autor o desejar, para uso na Primeira Fase da<br>Maratona de Programação, cuja prova ocorrerá no dia 12 de setembro de<br>2015.<br><br><br>Sugestões para escrever um bom problema<br>----------------------------------------<br><br>* Se você nunca escreveu um problema, leia e estude ao menos uma prova<br>  inteira da regional latino-americana de anos passados antes de<br>  começar a escrever. Sugere-se estudar mais de uma prova.<br><br>* Para uma boa prova, necessita-se de problemas de todos os níveis de<br>  dificuldade.  Um bom problema não é equivalente a um problema<br>  difícil.<br><br>* Há muitos temas para problemas (grafos, programação dinâmica,<br>  geometria, aritmética, guloso, backtracking, estruturas de dados,<br>  etc.).  Geralmente grafos e programação dinâmica são os mais<br>  populares, mas os problemas das provas serão selecionados tendo<br>  diversificação em mente. Nota: é muito bom quando um mesmo problema<br>  toca vários temas.<br><br>* Procure deixar bem claro quais são as entradas válidas, incluindo<br>  limites para todos os parâmetros.<br><br>* Os problemas com saída única são preferíveis. Se sua ideia tem saída<br>  múltipla, há várias técnicas que podem ser usadas para facilmente<br>  transformá-la em um problema com saída única (resultados em ordem<br>  lexicográfica, solicitar apenas o mínimo e o máximo e não a<br>  descrição do conjunto completo de resultados, etc.).<br><br>* Os problemas de decisão são os mais difíceis de testar. Procure<br>  fazer com que as possíveis saídas de seu problema tenham vários<br>  valores (um inteiro, uma cadeia, etc.)<br><br>* A menos que a ideia de um problema seja diretamente relacionada à<br>  entrada/saída (por exemplo, problemas de parsing, ou de desenho na<br>  tela), tanto a entrada como a saída devem ser o mais simples<br>  possível de ler usando entrada/saída padrão (printf/scanf, cout/cin,<br>  BufferedReader/System.out).<br><br></div></div><br></div>