La idea es genial. Me encanta el nuevo estilo de problemas, especialmente aquellos que son triviales cuando se resuelven secuencialmente pero que resultan altamente no triviales en el entorno distribuido.
La ejecución de esa idea aún no es óptima. Uno de los principales problemas que percibo es la noción completa de entradas grandes que se transfirió del CodeJam regular (GCJ) … pero en CodeJam distribuido (DCJ) no es lo mismo en absoluto. En GCJ estoy ejecutando mi propio código en mi propia máquina, puedo tener una estimación bastante buena de su tiempo de ejecución en la entrada de tamaño máximo antes de descargarlo y ejecutarlo. La corrección de su salida es el único problema. Esto funciona bien En DCJ tenemos demasiados factores diferentes que están fuera de nuestro control. Es difícil estimar el rendimiento de la vida real de nuestro código en algunas máquinas remotas desconocidas. La interfaz testrun no siempre se puede usar debido a los diferentes límites de los diferentes problemas. Incluso si puede, es costoso, porque necesitamos dedicar tiempo a crear un caso de prueba grande e integrarlo en nuestro código, y luego dedicar más de 2 minutos a la espera de que se complete la prueba. Además, el resultado de dicha prueba aún no es representativo, porque nuestro caso de prueba cableado puede leerse más rápido de lo que sucedería durante la evaluación. Para colmo, los límites suelen ser bastante estrictos, y este no es solo el límite de tiempo. Por ejemplo, tenga en cuenta la gran cantidad de soluciones correctas que superaron por poco el límite de memoria en DCJ 16 ronda 1. Es demasiado fácil escribir una solución que sea asintóticamente correcta en todos los aspectos y, sin embargo, no cumple uno de los requisitos. Es demasiado difícil para los competidores descubrirlo por su cuenta. En mi humilde opinión, los organizadores de DCJ deberían pensar mucho sobre cómo resolver este problema en los próximos años.
Una posibilidad que viene a la mente es más comentarios. Cada envío “grande” puede colocarse en una cola de turnos y probarse en un caso de prueba a la vez a medida que los recursos estén disponibles; y los concursantes pudieron ver el informe de progreso de esta prueba, por ejemplo, “ya pasó 20 de 100 pruebas, el peor tiempo de ejecución de 4,7 segundos”, mientras que todavía tiene la capacidad de volver a enviar, independientemente de si la solución ya falló o no.
- ¿Qué tipo de desarrollador de software escribe más código?
- ¿Cómo se desarrolla un software si no tienen experiencia en codificación?
- ¿Cuáles son las cosas más importantes que hacen que un ingeniero de software se destaque de sus pares?
- ¿Debo elegir un contrato de desarrollador de software o un puesto de liderazgo a tiempo completo?
- Cómo comenzar a contribuir en proyectos de código abierto
Además, como cada presentación “fácil” ya viene con una penalización de tiempo inherente, ¿existe realmente la necesidad de los minutos de penalización de +4 para cada reenvío? Este es otro sobrante de GCJ que se puede eliminar de forma segura. Junto con el cambio anterior, incluso podría tratar todos los subproblemas de la misma manera.
La ejecución de este año (2016) fue una mierda. Pasé dos de las tres horas de la ronda 1 esencialmente depurando por qué una característica que se prometió que no funcionaba. (A veces, mi solución que intentaba enviar mensajes que se encontraban dentro de los límites establecidos fue juzgada como “Infracción de la regla”). Mis preguntas sobre el tema aparentemente fueron mal entendidas y / o ignoradas. No fue nada divertido, quiero resolver las tareas de la competencia en lugar de luchar contra el medio ambiente y discutir con los organizadores. Solo cuando mencioné el mismo problema durante la ronda de práctica entre las rondas 1 y 2, los organizadores reconocieron el problema. ¿Qué siguió? Radio silencio. Y aparentemente el error, sea lo que sea, no se solucionó cuando apareció la ronda 2, por lo que el problema se “resolvió” silenciosamente al introducir en silencio un nuevo límite de tamaño de mensaje mucho más pequeño. Esto luego hizo tropezar a algunos competidores en la ronda 2, ya que no había (hasta donde sé) ningún anuncio al respecto, y no notaron el nuevo límite oculto entre todos los otros límites.
Comparando los dos años, disfruté mucho más de DCJ 15. En algunos momentos, DCJ 16 se sintió como si todos los organizadores que sabían lo que estaban haciendo se fueran, y los que quedaban se quedaron en sus cabezas. Además del problema mencionado anteriormente, las tareas de la ronda 2 de DCJ 16 me parecieron bastante aburridas, casi no había nuevas ideas (para alguien que resolvió los concursos anteriores), solo mucha codificación técnica fea.
Para terminar con una nota positiva, todavía es casi seguro que participaré en DCJ 17, si hay un DCJ 17 y mi horario lo permite. Entiendo que esta nueva competencia todavía es un trabajo en progreso, y lo que mencioné anteriormente son solo dolores de crecimiento. Es genial que alguien intente ejecutar este tipo de competencia, y espero ver en qué se convertirá en el futuro.