Feedback Entregas 1 y 2

[fisa]

Buenas!

Ya están corregidas las entregas 1 y 2. No hay grupos desaprobados (recuerden que la nota para esto era solo aprobado/no aprobado). Pero les damos un poco de feedback en general y algunas cosas más en particular, respecto a lo que vimos de cómo los resolvieron.

Además también respecto a un par de grupos que se copiaron las entregas entre sí.

############### Entrega 1 ##########################

En general muy bien, bastante claros y bien resueltos! Salvo por las heurísticas, que son casi todas no admisibles.

Sobre el estado, en general todos de 10, un par de detalles nomás:

- un par de grupos pusieron las paredes dentro del estado. Eso no sería muy útil porque es algo que no cambia durante la búsqueda, y ponerlo ahí dentro incrementa un poco el consumo de memoria innecesariamente. No es grave, pero aconsejamos no hacerlo.

- un grupo (G-4, Inwinkelried-Perret-Williner) se dio cuenta de que podían usar algo mejor que simplemente tuplas: diccionarios. En el estado llevan tuplas, pero al trabajar lo convierten a un dict que les facilita bastante las cosas. Bien!

Actions, result, cost e is_goal estuvieron re bien en general, sin comentarios especiales sobre esa parte.

Sobre las heurísticas: de 16 grupos solo 3 tienen heurística admisibles. 

G-09 (Duelli-Pierini-Pistarino) y G-66 (Clementz-Fornari-Pluda) tienen heurísticas admisibles aunque notablemente complejas de calcular, y G-14 (Asselborn-Caluva-Martinez-Morero) tiene una heurística admisible y bastante sencilla.

El resto, son todas no admisibles. Tienen uno o varios de los siguientes problemas:

- usan distancia de manhattan para estimar tiempos de movimientos faltantes, pero si el jedi salta usando concentración, el costo (tiempo) de moverse puede ser menor por ir en diagonal.

- calculan distancias a todos los grupos de droides desde la posición actual del jedi, lo que sobreestima la cantidad de movimiento que hace falta (si ustedes tienen que ir desde la univ hasta la municipalidad y la catedral, sumar distancia(univ,muni)+distancia(univ,catedral) re sobreestima el recorrido que tienen que hacer, porque al llegar al primer lugar ya quedan cerca del siguiente).

- asumen que siempre hay que usar un ataque de fuerza para limpiar un grupo de droides, cuando si es un solo droide se puede limpiar con un solo ataque de sable, que toma menos tiempo.

El grupo G-2 (Amerio-Griglio-Rossi) tiene un caso muy particular de no admisibilidad, que es difícil de explicar en texto pero podemos charlar en algún ratito en clases :) Tiene que ver con el ordenamiento que hacen y casos donde esas distancias son iguales (ej: jedi en el medio y 4 grupos de droides alrededor suyo equidistantes).

Por qué funcionaron si sobreestimaban en sus heurísticas? Porque en los casos sencillos de ejemplo que probamos en los tests no había complejidad suficiente de costos y estimaciones como para que el algoritmo termine encontrando una solución no óptima antes. O sea, fue suerte :D

############### Entrega 2 ##########################

En general muy bien también, bastante claros y bien resueltos!

Todos armaron bien variables y dominios. Y en general eligieron muy bien el scope de las restricciones, minimizando la cantidad de variables involucradas en casi todas ellas.

La gran mayoría también se dio cuenta de que la "restricción" unaria de que el jedi no puede estar en el borde, se podía hacer directamente limitando el dominio de esa variable, que es mucho mejor que agregar una restricción unaria.

Aunque solo dos grupos (G-1 Saulo-Lattanzi-Sterren, y G-7 Cravero-Gigon-Pastore) se dieron cuenta de que la restricción de no encerrar al jedi con paredes, se podía expresar como N restricciones de 5 variables, en lugar de una sola restricción involucrando a [jedi y todas las paredes]. Es mucho mejor pensarla como N restricciones de 5 variables, porque se puede detectar mucho antes el encerramiento del jedi, sin tener que esperar a asignar valor a todas las paredes del juego. Eso reduce muchísimo las combinaciones a probar.

Un detalle extra: hubo varios grupos que escribieron un puñado de funciones repetidas para las restricciones de "droide no en mismo lugar que otro droide", "pared no en mismo lugar que droide", "pared no en mismo lugar que jedi", etc.

Eran todas iguales: recibir dos variables, y chequear que no tengan el mismo valor. Se podía definir una sola vez una función de "no_iguales", y reutilizarla para todas esas restricciones.

No rompe nada, pero es mucho código extra que se pueden ahorrar :)

############### Copias ##########################

Hay dos grupos que tienen las Entregas 1 casi idénticas. Solo cambia el código de la función actions, lo demás es todo copiado y pegado nomás tuneando un poco el nombre de las variables para que no se note.

Como es normal colaborar y ayudarse entre grupos, es esperable que haya soluciones similares. Y el límite entre "colaborar" y "copiar" a veces puede ser borroso (ej: quizás se juntan y discuten juntos un problema puntual en común, y luego esa parte queda igual en ambos). Hay varios grupos con cosas muy similares que caen en esa zona "borrosa".

Pero este caso puntual está lejos de ser borroso, sino que está muy claro que fue copiado. El 90% de la entrega es idéntica.

Entiendan que quien entrega código ajeno como si fuese propio se está perjudicando a sí mismo, ya que las entregas están pensadas para que ustedes aprendan y practiquen al resolverlas, cosas que como mínimo ayudan a luego hacer bien el parcial/final y aprobar la materia, y ni hablar si tienen intención de aprender de verdad. Si se las hace alguien más, se privan de practicar y aprender ustedes.

Ponemos bastante esfuerzo en estas entregas (ej: tomó todo el finde largo en corregirlas), y es solo para ustedes.

Felicitaciones a todos los que las aprovecharon!

Saludos!

--

fisa  -  Juan Pedro Fisanotti