Bueno aca les dejo el final tomado el dia de la fecha, espero les sirva.

Saludos

Buenas, yo hoy rendi y me fue mal. Alguien tiene la resolucion?

Gracias!

(14-02-2015 20:08)pollo escribió:  Buenas, yo hoy rendi y me fue mal. Alguien tiene la resolucion?

Estoy en la misma que vos, alguno que pueda poner la resolución por favor?

Buenas tardes,

Les dejo la resolucion del final. Cualquier cosa consulten tranquilos

(19-02-2015 15:28)Motomine escribió:  Buenas tardes,

Les dejo la resolucion del final. Cualquier cosa consulten tranquilos

Hola, mas que criticar, te consulto. Estas seguro de la resolucion del ultimo punto (funcional) ? Lo probaste ?

Te falta pasarle la función que vas a mapear.

Tenes:
banquete comer = map comer
Que está mapeando?

Hola, esa funcion esta bien hecha, pruebenla sino. Capaz debi aclararlo, comer es una funcion, estoy usando aplicacion parcial, por lo que no escribo la lista del ultimo parametro. Lo que escribi es lo mismo que hacer:

banquete comer personajes = map comer personajes

Por si no lo vieron en la cursada les digo, cuando la lista esta aplicada de esa forma se puede simplificar igual que hacian en analisis matematico: si tienen f(x) . y = g(x) . y se pueden simplificar las y, aca es igual.

O sea que comer es una lista de funciones. Ok.
Pero en realidad, las listas en haskell no pueden tener elementos de diferente tipo.
Y si te fijas:

comerTerricola es un tipo, comerNamekiano es de otro, y asi...

Si no entendi mal, lo que piden es que vos tengas codificado banquete unosPersonajes = map comer unosPersonajes y que ese codigo no se modifique nunca ( ni agregando ni demonios ni nada).

En tu solucion, como crearias una lista de personajes "mezclada" ? O sea como pones un terricola, un namekiano, y un saiya en una misma lista ?
Como le das de comer a todos en una sola linea de codigo ?

Por lo que yo entiendo del enunciado que explicita que se manejan las listas por separado, la idea es hacer una funcion sola que sea parametrizable, en lugar de hacer 3 iguales cambiando dos letras. Lo que yo hice no usa una lista de funciones... que sentido tendria?
Lo que hice es una funcion banquete que recibe dos parametros, una funcion y una lista de personajes de un mismo planeta. El que llame a la funcion sabra que hacer.
Si se les va a dar de comer a los terricolas se llamara a la funcion asi: banquete comerTerricola listaDeTerricolas.

Justamente el enunciado dice aprovechando la similitud parcial entre dos funciones. La idea del punto es que demuestres que sabes usar orden superior, para que definir 3, 4, 5... n veces lo mismo? (map unaFuncion unaLista). Si mas adelante cuando comen se agrega la condicion que filtra algo tendria que agregarse esa condicion a todas las funciones desarrolladas, de esta forma se agrega el filter aca y listo (filter unaCondicion . map unaFuncion $ unaLista).

Una lista de personajes mezclada no se podria hacer, el problema esta en que el namekusei y sayajin tienen la misma estructura, entonces no se sabe que calculo aplicarle. Por eso la unica solucion factible es la planteada hasta lo que se me ocurre.

Ok. Ahora sí.
Igual no me queda claro en donde se puede "aprovechar la similitud" si en realidad ni haskell ni prolog permiten reusabilidad de codigo.

Se refieren a la similitud parcial que tienen comerNamekusei y comerSayajin, que en ambas hay un map y una funcion con abstraccion (no una lambda como en el primer caso, aunque yo aproveche esa similitud para mejorar la solucion en general).

Dejo la resolución que hice yo, (no esta corregida).
El punto que mas me complico la vida fue el de funcional, que lo resolví aplicando polimorfismo con orden superior, aunque tuve que cambiar la tupla.
-------------------------------------------------------------------------------------------
PARTE A

1. No funciona cuando realiza self cantidadDeAliados, la clase blanquete no entiende ese mensaje.
2.
a) Polimorfismo. No posee polimorfismo.
b) Herencia. No existe la herencia en esta solución.
c) Encapsulamiento. No respeta encapsulamiento, el banquete resuelve todo lo que le corresponde a los personajes. (Se aplica unicamente por los setters y getters, y es un caso trivial).
3.
#Banquete (vi: invitados,nombre)
>>comer
invitados do: [ :invitado | invitado comer ]

#Personaje [es abstracta] (v.i.: energia, nombre) (con getters y setters)
>>comer
self energia: self energia + self energiaPorComida

#Terricola (es subclase de Personaje)
>>energiaPorComida
^200

#Extraterrestre [es abstracta] (v.i.: cantidadDeAliados) (con getters y setters) (es subclase de Personaje)
>>energiaPorComida
^100 * self cantidadDeAliados

#Namekusei (es subclase de Extraterrestre)
>>energiaPorComida
^ (super energiaPorComida) + 10

#Saiyajin
>>energiaPorComida
^ (super energiaPorComida)*2

4.
Los conceptos aplicados en la nueva solucion fueron: polimorfismo, delegacion, herencia, encapsulamiento.
El encapsulamiento esta en que el Banquete permite que cada clase que hereda de Personaje, defina como comer. Aqui mismo, se ve el funcionamiento del polimorfismo, ya que todas estas clases redefinen el metodo energiaPorComida para saber como modificar su energia. La delegacion esta en que, para evitar la repeticion de codigo, opte por solo redefinir aquellas porciones de codigo que no estaban descriptas anteriormente.
5.
#Demonio (subclase de Personaje) (v.i.: victimas)
>>energiaPorComida
^200 + (victimas size * 10)

El encapsulamiento porque pude definir una nueva clase que entiende como comer, sin modificar a nadie mas. Herencia, porque heredo de una clase que ya sabe comer. Y polimorfismo, ya que todos los invitados entienden energiaPorComida.
---------------------------------------------------------------------------
PARTE B

1.
a. ?- comer(goku,vegeta,500,5). => false. Debido a que 500 no es 1500.
b. ?- comer(piccolo, namekusei, Energia, 3). => false. Debido a que Energia no esta unificado al momento de utilizar is, que no es inversible.

2.
comer(_,tierra,Energia,_,EnergiaResultante):-
EnergiaResultante is Energia + 200.
comer(_,namekusei,Energia,Aliados,EnergiaResultante):-
EnergiaResultante is Energia + 100*Aliados + 10.
comer(_,vegeta,Energia,Aliados,EnergiaResultante):-
EnergiaResultante is Energia + 100*Aliados*2.
3.
Podria haber representado los diferentes personajes con functores. La ventaja que tendria seria que al predicado comer le podria enviar cualquier tipo de personaje con cualquier comportamiento, haciendolo polimorfico.
4.
comer(personaje(_,tierra,Energia),EnergiaResultante):-
EnergiaResultante is Energia + 200.
comer(personaje(_,extraterrestre(Planeta),Energia,Aliados),EnergiaResultante):-
Adicional is 100 * Aliados,
variacion(Planeta, Adicional, VariacionReal),
EnergiaResultante is Energia + VariacionReal.
comer(personaje(_,demonio,Energia,Victimas),EnergiaResultante):-
EnergiaResultante is Energia + 200 + 10 * Victimas.

variacion(namekusei, Adicional, Variacion) :- Variacion is Adicional + 10.
variacion(vegeta, Adicional, Variacion) :- Variacion is Adicional * 2.

Aproveche los functores para realizar el predicado comer en forma polimorfica, ya que los personajes de la tierra no tienen aliados como los extraterrestre, ni victimas como los demonios.
Tambien utilice delegacion para no repetir codigo para el caso de los extraterrestres. El functor que pide el planeta del extraterrestre es para que unifique por pattern matching solo aquello que sean extraterrestres.
5.
No es inversible dado que no tengo predicados generadores, y el operador is necesita que su lado derecho este unificado.
----------------------------------------------------------------------
PARTE C

1. Si, funciona correctamente.
2.
banqueteExtraterrestres = map comerExtraterrestres
comerExtraterrestres (nombre,energia,cantAliados,variacion) = (nombre, energia + variacion (100*cantAliados),cantAliados,variacion)

variacionNamekusei = (+10)
variacionVegeta = (*2)

Para simplificar la solucion, agregue a la tupla la variacion, que es una funcion de como varia para cada extraterrestre (namekusei o vegeta). Entonces los conceptos aplicados son orden superior, polimorfismo sobre la variacion de cada extraterrestre, y aplicacion parcial para cada variacion.
3.
banqueteDemonios = map comerDemonio
comerDemonio (nombre,energia,victimas) = (nombre, energia + 200 + (victimas*10), victimas)

Hola, te hago unos comentarios de tu resolucion:

- Lo que pusiste como encapsulamiento es mas orientado para el lado de la delegacion (que el banquete resuelve lo que le corresponde al personaje).

- El persnaje no entiende el metodo energiaPorComida, no lo podes llamar desde ahi y definirlo en las subclases. La idea la tenes bien,pero eso que planteas no va a funcionar.

- Lo que pusiste en la segunda respuesta de prolog tira error, no false (por la justificacion que pusiste).

- En el punto 1 de haskell habia que justificar, se dijo oralmente (se lo re olvidaron en el enunciado)

- No esta bien que modifiques las tuplas para que la funcion correspondiente este en uno de sus parametros. Si bien funciona, estas modificando la estructura de los extraterrestres.


Hago estas aclaraciones porque le pueden servir a alguno que vaya a dar el final. La solucion que subi previamente tambien puede tener algun error, no se si estara de maravilla.
Yo el sabado estuve en la correccion en la parte de objetos, por eso en las otras digo mi opinion y no garantizo que sea la respuesta perfecta.

Gracias Motomine por tu tiempo!,
1) Seguro que no andaria? Es decir, es una clase abstracta el personaje, y todos los que heredan si implementan el metodo comerPorEnergia.
2)Estaría mal poner false y justificar bien? me cuesta diferenciar que es error y no false.
3)No tenia idea, estoy preparando el final para el sabado, ja .
4)Si no modificaba la tupla me veía obligado a repetir cada caso, capaz estoy exigiendo demasiado. Tendria que ir por una solución como la pasaste vos. (que obviamente esta bien y usa orden superior). Es que me quede pensando en el tema del que enunciado decia sobre la semejanza de las tuplas de extraterrestres, y crei que la idea era encontrar algo polimorfico.

En fin, mil gracias!