search

alfonsodou / javaCup

Framework javaCup
3 stars 3 forks source link

Optimización #12

Open alfonsodou opened 10 years ago

alfonsodou commented 10 years ago

Otra historia que queda muy de lado es el de la optimización. Por mi vida laboral, es casi la parte más importante del trabajo, y quizá a veces lo lleve a todos los campos, pero tratándose de un 'concurso' de programación, es algo que no debería quedar en el olvido. Con las tácticas del año pasado, llegué a esperar casi un segundo a que ciertas tácticas hiciesen una sola iteración donde podían golpear el balón. ¿Por qué no limitar esto? ¿Por qué no hacer una medición y limitar la optimización? Entraría en juego otro aspecto muy importante y que haría equilibrar todo un poco. No sería el mejor el que más casos analizase e interpretase, sino que además debería hacerlo en un tiempo computacional razonable, al igual que un jugador tiene un tiempo limitado a la hora de tomar la decisión de un pase/tiro/lo que sea... Ahora la normativa es bastante vaga en este aspecto, puesto que refiere a las tácticas anteriores para ponerse en un lugar similar. También es verdad que me parece bastante raro que ciertas tácticas de este año se mantengan en los niveles de computación de años anteriores, pero eso es otra historia que creo que se debería tratar aparte.

alfonsodou commented 10 years ago

Solución propuesta:

volviendo al tema del timeout: siempre existe la solución tonta basada en guardar el timestamp previo a cada iteración y una vez completada la iteración validar el tiempo que ha tardado cada equipo en responder. Si en una iteración te pasas, tus comandos no entran en la lista de comandos a ejecutar. Algo como esto:

List comandosLocales = new LinkedList(); try { long startTime = System.currentTimeMillis() List comandosPropuestos = tacticaLocal.execute(spLocal); if(System.currentTimeMillis() - startTime <= MAX_PROCESSING_TIME){ comandosLocales = comandoPropuestos; } else { // activar flag para evitar recuperación energía en la presente iteración // el flag se desactiva en el método encargado de recuperar la energía } } catch (Exception e) { logger.severe("Error al ejecutar tactica local: " + e.getMessage()); }

la elección de la constante MAX_PROCESSING_TIME sería la parte más delicada del asunto...

además, como se ve en el código propuesto, el infractor no debería recuperar energía en esa iteración pq no ha dejado quietos a los jugadores por propia voluntad.

es algo más rupestre y sigue consumiendo todo el tiempo que la táctica infractora quiera... pero ese equipo terminaría suficientemente penalizado como para que te salga más a cuenta chutar mal y rápido que procesar una barbaridad de trayectorias.

http://www.javahispano.org/foro-de-la-javacup/post/2227275