UTNianos

Versión completa: [APORTE] Paradigmas de Programación - Final 27-02-2016
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Hola gente! Les dejo el final tomado hoy de Paradigmas.

[attachment=12717] [attachment=12718] [attachment=12719]

Saludos!
Gracias por el aporte.
Alguien lo puede resolver y compartirlo? mas que nada la parte de funcional.

Gracias
Gente alguno pudo resolver la Parte A, recien la trate de hacer y me dan ganas de no presentarme al final el sabado jaja.

Si alguno la tiene y la puede subir muy agradecido

Saludos
Buenas gente, acabo de resolver la Parte A

A1: v1 y v2 son equivalentes por la currificación, y con v3 ya que utiliza expresión lambda (funcion anonima que solo utilizo en ese contexto).
v4 falla por definición de la función on.

A2a: La sintaxis es correcta, pero la iteración entraría en un loop infinito.
A2b: son expresiones de composicion, aplicacion parcial y orden superior
- no funciona, falta un parametro
- funciona, loop infinito (este punto me exploto la ram de la pc).
- funciona loop infinito.

Creo que es todo, voy a continuar resolviendo el resto de los puntos, si alguno puede aportar algo mas a la resolución, se lo agradecería.

*Aclaración: las respuestas son en base a resultados arrojados desde haskell.


Saludos.
Leo.
Paso la resolución del resto de puntos.

Parte B
b1) profesion(ted,arquitecto).
profesion(lily, maestra).
profesion(marshal, abogado).
profesion(barney, desconocido).

b2) No se puede resolver sin la utilizar listas, ya que no se pueden relacionar los elementos por si solos y obtener el maximo (no contamos con la funcion max en prolog). Tambien es un requsito utilizar orden superior, ya que findall arma la lista y es una función de orden superior.

b3) foo xs = elem (1,_) xs Es incorrecta, ya que elem no puede recibir una tupla.


Parte C
Rigoberto planteo una mejor solución ya que resuelve los distintos comportamientos, a travez de la herencia.

Ca) 1. no existe el polimorfismo, solo envia el mensaje a la variable de instancia para obtener el sueldo base.
2. el beneficio es la utilización del polimorfismo para el calculo del sueldo total, ya que abstraigo del tipo de empleado que tiene mi coleccion.
Cb) 1. No utiliza polimorfismo.
2. En sueldoBase
Cc) Pancracio deberia mejorar la solución, dividiendo las responsabilidades de cada tipo de empleado, como lo plantea Rigoberto que utiliza la herencia, abstracción y polimorfismo, que son algunas de las bases de la programación orientada a objetos.



Algunas de las justificaciones se pueden ampliar, aunque en los finales sugieren que no se guitarreé, asi que trate de ser lo mas escueto posible en las respuestas.



Si tienen algun otro final de 2016 subanlo que tengo pensado rendir el sabado y no encontre finales de este año en la pagina de pdep.


Saludos,
Leo.
Hola! para la parte A, en head. iterate (+1) esta aplicado parcialmente y toma el primer valor (por head)..
Saludos!
(14-07-2016 12:35)lrodriguez84 escribió: [ -> ]Buenas gente, acabo de resolver la Parte A

A1: v1 y v2 son equivalentes por la currificación, y con v3 ya que utiliza expresión lambda (funcion anonima que solo utilizo en ese contexto).
v4 falla por definición de la función on.

A2a: La sintaxis es correcta, pero la iteración entraría en un loop infinito.
A2b: son expresiones de composicion, aplicacion parcial y orden superior
- no funciona, falta un parametro
- funciona, loop infinito (este punto me exploto la ram de la pc).
- funciona loop infinito.

Creo que es todo, voy a continuar resolviendo el resto de los puntos, si alguno puede aportar algo mas a la resolución, se lo agradecería.

*Aclaración: las respuestas son en base a resultados arrojados desde haskell.


Saludos.
Leo.

Puede ser que con el tipo de la función pida la firma? tipo a -> a -> b en lugar de los conceptos que aplica? No estoy seguro..
Claro, en el punto 2b de la parte A se pide el tipo de cada una..

- Num a => a -> a
- Num a => Int
- Num a => [[a]]

(de las 2 ultimas, no estoy muy seguro..)

Saludos!
Medio viejo, pero por si alguno anda revisando finales....
La parte B,
el b2 si puede resolverse sin listas....


ganador(Ganador):-
puntos(Ganador,PuntosGanador),
forall(puntos(Persona2,Puntos2),(PuntosGanador>=Puntos2)).


(El orden superior queda).

y el b3 es incorrecta la de Haskell pero NO porque elem no pueda recibir una tupla, sino porque se le puso el "_"... y parece romper todo ja
URLs de referencia