ramirez7358 / estrd22s1 Goto Github PK

El enunciado pide explícitamente que se contemplen, pues establece que NO debe ser un error. Así como está definida, los números negativos se cuelgan.

Ya sé que es una práctica de recursión... Pero siempre es mejor usar las herramientas más simples disponibles. ;)

Como faltan casos, hay situaciones para las que se cuelga...

No es necesario que el tipo Entrenador tenga un par de Pokemon. Puede tener ambos Pokemon directamente, sin el par.
Eso te complica después las funciones...

O sea, si un proyecto p particular aparece 3 veces, ponés 3 elementos (p,3) en la lista final, y esto no es feliz.
Además, estás recorriendo muchísimas veces todos los proyectos de la empresa, lo que no es muy bueno.
La idea es usar recursión estructural sobre los proyectos de la empresa...

Algunos de Pokémon y todos los de Empresas.

Usá directamente (==)... Por regla general, no es feliz hacer renombre de funciones sin otro propósito que cambiarle el nombre. Debería haber alguna razón más que solo eso...

Al usar ps en lugar de proyectosSinRepetidos ps en la condición, mirás más veces de las necesarias.
Esto es en general para cuando querés remover duplicados...

Este tema lo vimos en clase...

NO está permitido usar la característica deriving en algo diferente de la clase Show (en esta materia).

NUNCA devolvemos True o False en un if. Hay formas más comunicativas de decir lo mismo. Nuevamente, es un tema que vimos en la práctica 1.

Siempre da False, ya que nunca usa el número que le estás pasando para nada más que para decrementarlo...

No es adecuado escribir if cond then True else False porque es lo mismo que cond.

NUNCA hagas doble PM si no es necesario. Y SIEMPRE agotá los casos de un parámetro antes de mirarel otro... (cuando es necesario mirarlo, que no es este caso).

¿Por qué hacer recursión sobre AMBOS parámetros, si alcanza con hacerlo sobre UNO SOLO?
Esto te lleva a equivocarte en la cantidad de bolitas que pone... ¿La probaste?

Porque es una auxiliar que debe ARMAR una negación según sea el argumento. Y lo que hace es sacar doble negación directamente, sin agregar nada, por lo que cambia el significado...
Funciona por propiedades accidentales de la negación, pero no es feliz que sea así.

Lo trabajamos en la práctica 1, y se supone que no vuelvan a cometer los mismos errores...
Un truco para hacer eso es REUTILIZAR, en lugar de reinventar todo cada vez...

La función vieneDespues definida no es la pedida. Por ejemplo, Miercoles viene después que Lunes, pero tu función no lo indica adecuadamente, porque solamente considera el caso inmediato siguiente, y no todos.

Atención al corregirla de no caer en una explosión combinatoria de casos. El consejo es usar subtareas adecuadas.

Es importante que aprendan a respetar las consignas al pie de la letra...

Toda la idea de esta práctica es usar recursión estructural, por lo que la solución ofrecida es inadecuada.

Por otra parte, en esta definición, la ecuación 1 es innecesaria, porque está cubierta por la siguiente. Si vas a hacer una solución con subtareas, no deberías mirar casos particulares...

Al utilizar una función auxiliar sobre los subárboles, se pierde la idea de recursión estructural (y se trabaja de más).
Pensá por recursión estructural... (y subtareas)

Básicamente, si se cambia la definición de entrenador, se te complica esta función...
Además, al mirar a los dos al mismo tiempo estás repitiendo trabajo que debería ser para subtareas.
Finalmente, si bien no está mal usar fst y snd, estaría bueno que practiques el uso de PM, porque lo vamos a usar mucho...

Básicamente, pierde elementos. Los elementos que sobran en cualquiera de las 2 listas deberían ser parte de la solución (o sea, en ese sentido esta función no es igual a zip).

No es feliz ofrecer más de una solución sin elegir alguna, o sin establecer las ventajas y desventajas de cada una de ellas. Eso muestra indecisión y acá se trata de poder tomar decisiones...

La función and de la práctica 1 debería comportarse de la siguiente manera:

> and False (error "Mal")
False

Sin embargo, tu versión da error "Mal".
Así, no es la función pedida.

Exactamente lo mismo pasa con la función or, que debería pasar el test or True (error "Mal") dando True.

Es interesante de pensar. Consejo: dividir en subtareas... ;)