Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Autor Mensaje
viktorxD Sin conexión
Profesor del Modulo A
Clases de ModuloB Analisis1
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 291
Agradecimientos dados: 68
Agradecimientos: 304 en 96 posts
Registro en: May 2013
Mensaje: #1
Tongue [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017 Finales Paradigmas de Programación
FINAL de 18/02/2017

Bien.
Cuento como Asignaron puntos, en base a lo que vi en el Pizarron.
Parte A 6puntos
1 -2
2 - 2
3 a-0,5 b-0,5
4 1

ParteB 5 puntos
1
a-0,5
b-0,5
c-0,5
d-1

2
a-0,5
b-2

ParteC 3 puntos
1 -1
2-2

Dejo mi resolución.

La parte A Fíjense, Seguro contiene errores.
La parteB deberia estar bien, no me Di cuenta que había B2

La parte Parte C 2
La había hecho con findall + forall
Estaba fea, en esta versión la mejore.

O sea que raspe en Funcional por boludo
En Lógico mi código andaba pero estaba feo.
Y en el A lo hice lo más rápido posible, sino me iba a mi casa.

Saque 4.

Espero les sirva.

Saludos!


Archivo(s) adjuntos
.pdf  FinalPdeP2017-02-18.pdf (Tamaño: 1,36 MB / Descargas: 528)
.pdf  ResolucionVIKTORFinalPdeP.pdf (Tamaño: 874,59 KB / Descargas: 196)
Otros adjuntos en este tema
.jpg  ParteB-1a.b.c.d_1.jpg ( 456,75 KB / 618) por viktorxD
.jpg  ParteC_1.jpg ( 426,9 KB / 586) por viktorxD
.jpg  ParteA_1(2).jpg ( 425,44 KB / 595) por viktorxD
.jpg  ParteAA_1.jpg ( 433,99 KB / 583) por viktorxD

(Este mensaje fue modificado por última vez en: 24-02-2017 01:08 por viktorxD.)
18-02-2017 12:25
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] viktorxD recibio 6 Gracias por este post
JPfx (18-02-2017), TobiasVosk (19-02-2017), Leo13 (22-02-2017), macmolin (24-02-2017), MoxPawer (10-07-2017), Smitten1994 (15-07-2017)
TobiasVosk Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 11
Agradecimientos dados: 8
Agradecimientos: 5 en 2 posts
Registro en: Jun 2014
Mensaje: #2
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Viktor como te fue? Vi que dijiste que te ibas a presentar ayer.

Te hago una pregunta, la parte A la saque re bien creo, era bastante tranqui. Pero en la parte B, estoy medio confundido con el punto 2. Como lo planteaste vos?
19-02-2017 11:32
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
JPfx Sin conexión
Empleado del buffet
Menos estado que Palestina
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 20
Agradecimientos dados: 18
Agradecimientos: 8 en 4 posts
Registro en: Jul 2014
Mensaje: #3
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Buenas... alguien sabe si dejan usar la guía de lenguajes en el final?
21-02-2017 15:04
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Arito04 Sin conexión
Empleado del buffet
Si la vida es larga y dura... ...
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 8
Agradecimientos dados: 10
Agradecimientos: 1 en 1 posts
Registro en: Jul 2012
Mensaje: #4
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
(21-02-2017 15:04)JPfx escribió:  Buenas... alguien sabe si dejan usar la guía de lenguajes en el final?

Si, te la dejan usar.

(18-02-2017 12:25)viktorxD escribió:  FINAL de 18/02/2017

Te hago una consulta, dieron los clasicos 15 min para verlo e irte si no te sentis muy seguro? blush
(Este mensaje fue modificado por última vez en: 21-02-2017 16:02 por Arito04.)
21-02-2017 16:02
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Arito04 recibio 1 Gracias por este post
JPfx (21-02-2017)
viktorxD Sin conexión
Profesor del Modulo A
Clases de ModuloB Analisis1
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 291
Agradecimientos dados: 68
Agradecimientos: 304 en 96 posts
Registro en: May 2013
Mensaje: #5
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
(19-02-2017 11:32)TobiasVosk escribió:  Viktor como te fue? Vi que dijiste que te ibas a presentar ayer.

Te hago una pregunta, la parte A la saque re bien creo, era bastante tranqui. Pero en la parte B, estoy medio confundido con el punto 2. Como lo planteaste vos?

Hola!
Aprobé por suerte, ahí con lo justo.
Ni idea el B2
Me di cuenta que existía el B2 cuando estaba en el Buffet hablando con un compañero que rindió y ya eran 11 menos 10 así que dije ya fue...

(21-02-2017 16:02)Arito04 escribió:  Te hago una consulta, dieron los clasicos 15 min para verlo e irte si no te sentis muy seguro? blush

Cálculo que Si, porque pasabas y no entregabas tu libreta.
La dejabas en la mesa y luego ellos pasaban, no vi salir a Nadie, pero porque no levanté levante la cabeza del Banco, me quedé.

(Este mensaje fue modificado por última vez en: 21-02-2017 17:14 por viktorxD.)
21-02-2017 17:11
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
TomTom Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 25
Agradecimientos dados: 11
Agradecimientos: 6 en 5 posts
Registro en: Jul 2016
Mensaje: #6
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Hola a todos, hice la Parte A, para discutir. Ahora voy a hacer los otros y también los posteo!

Parte A

Spoiler: Mostrar
1.:

Errores conceptuales:

Las variables están todas asignadas sin manera de hacerles un cambio, por lo que cada vez que se cree un objeto de la clase "futbolista", estos van a ser todos iguales. Debería agregarse un construct, y así cada vez que se crea un futbolista asignarle sus valores y habilidades propias.

Por el otro lado, "nivelGambetero" es una variable que está de más. El nivel de la habilidad debería saberlo cada habilidad.

La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista. No se hace uso de polimorfismo para tener un código más robusto, general y adaptable.

2.:

class futbolista {

var edad
var altura
var peso
var habilidades


constructor (unaEdad, unaAltura, unPeso, unasHabilidades){
edad = unaEdad
altura = unaAltura
peso = unPeso
habilidades = unasHabilidades
}
method peso(){
return peso
}
method altura(){
return altura
}
method edad(){
return edad
}

method puntaje(){
return habilidades.sum({habilidad => habilidad.puntajeUnico(self)})
}

}

class forzudo{

method puntajeUnico(jugador){
return jugador.peso() * jugador.altura()
}
}

class gambetero{

var nivelGambetero

construct(unNivel){
nivelGambetero = unNivel
}

method puntajeUnico(jugador){
return nivelGambetero / (jugador.peso() * jugador.altura())
}

class rapido{

method puntajeUnico(jugador){
return edad / (jugador.peso() * jugador.altura())
}

De esta manera, al crear al jugador podemos especificar todos sus atributos, y luego cada habilidad se encarga de calcular su propio puntaje según el jugador, siendo así un codigo más adaptable (ya que si quiero agregar más habilidades solo debo crear su respectiva clase y no hacer ningún tipo de modificación al resto del codigo) y más declarativo.

3.a:

La manera más facil de hacer esto es que se cree una variable "alturaCalculo" (var alturaCalculo = 1,70) y un setter y getter de esta, de esta manera si en algún momento esta debe ser cambiada, cabe la posibilidad de hacerlo sin ninguna modificación en el código.

3.b:

Siguiendo las modificaciones propuestas en el punto anterior, crearía una clase con un metodo "puntajeUnico" que calcule de manera especifica para cada nueva habilidad.

4:

Ayuda ya que si no se delegaría el calculo del puntaje de cada habilidad, cada vez que se agregue una deberían agregarse ifs, variables, y modificaciones que hacen el codigo poco declarativo, engorroso y cada vez menos modificable.


AGREGO LA PARTE C

Parte C
Spoiler: Mostrar
1.:


a. Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta.

b. Falso, la solución no es declarativa ya que se abusa el uso del findall, haciendola repetitiva, mas allá de que este sea un predicado de orden superior, generando una solución procedural.

c. Falso, se pueden tratar polimorficamente creando predicados iguales que utilicen todos los tipos de actividades.

2.:

seAchancho(Persona):-
actividad(Persona, _),
forall(actividad(Persona, Actividad), not(esFisico(Actividad))).

esFisico(deporte(Nombre)):-
actividad(_, deporte(Nombre)).
esFisico(subirEscaleras(Pisos)):-
actividad(_ , subirEscaleras(Pisos)),
Pisos > 4.

De esta manera implementamos el concepto de polimorfismo con "esFisico" y además creamos una solución más simple y declarativa que solo verifica lo que pide el enunciado "que ninguna actividad sea física".
(Este mensaje fue modificado por última vez en: 23-02-2017 13:51 por TomTom.)
23-02-2017 12:49
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Arito04 Sin conexión
Empleado del buffet
Si la vida es larga y dura... ...
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 8
Agradecimientos dados: 10
Agradecimientos: 1 en 1 posts
Registro en: Jul 2012
Mensaje: #7
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
(23-02-2017 12:49)TomTom escribió:  Hola a todos, hice la Parte A, para discutir. Ahora voy a hacer los otros y también los posteo!

Parte A

Spoiler: Mostrar
1.:

Errores conceptuales:

Las variables están todas asignadas sin manera de hacerles un cambio, por lo que cada vez que se cree un objeto de la clase "futbolista", estos van a ser todos iguales. Debería agregarse un construct, y así cada vez que se crea un futbolista asignarle sus valores y habilidades propias.

Por el otro lado, "nivelGambetero" es una variable que está de más. El nivel de la habilidad debería saberlo cada habilidad.

La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista. No se hace uso de polimorfismo para tener un código más robusto, general y adaptable.

2.:

class futbolista {

var edad
var altura
var peso
var habilidades


constructor (unaEdad, unaAltura, unPeso, unasHabilidades){
edad = unaEdad
altura = unaAltura
peso = unPeso
habilidades = unasHabilidades
}
method peso(){
return peso
}
method altura(){
return altura
}
method edad(){
return edad
}

method puntaje(){
return habilidades.sum({habilidad => habilidad.puntajeUnico(self)})
}

}

class forzudo{

method puntajeUnico(jugador){
return jugador.peso() * jugador.altura()
}
}

class gambetero{

var nivelGambetero

construct(unNivel){
nivelGambetero = unNivel
}

method puntajeUnico(jugador){
return nivelGambetero / (jugador.peso() * jugador.altura())
}

class rapido{

method puntajeUnico(jugador){
return edad / (jugador.peso() * jugador.altura())
}

De esta manera, al crear al jugador podemos especificar todos sus atributos, y luego cada habilidad se encarga de calcular su propio puntaje según el jugador, siendo así un codigo más adaptable (ya que si quiero agregar más habilidades solo debo crear su respectiva clase y no hacer ningún tipo de modificación al resto del codigo) y más declarativo.

3.a:

La manera más facil de hacer esto es que se cree una variable "alturaCalculo" (var alturaCalculo = 1,70) y un setter y getter de esta, de esta manera si en algún momento esta debe ser cambiada, cabe la posibilidad de hacerlo sin ninguna modificación en el código.

3.b:

Siguiendo las modificaciones propuestas en el punto anterior, crearía una clase con un metodo "puntajeUnico" que calcule de manera especifica para cada nueva habilidad.

4:

Ayuda ya que si no se delegaría el calculo del puntaje de cada habilidad, cada vez que se agregue una deberían agregarse ifs, variables, y modificaciones que hacen el codigo poco declarativo, engorroso y cada vez menos modificable.


AGREGO LA PARTE C

Parte C
Spoiler: Mostrar
1.:


a. Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta.

b. Falso, la solución no es declarativa ya que se abusa el uso del findall, haciendola repetitiva, mas allá de que este sea un predicado de orden superior, generando una solución procedural.

c. Falso, se pueden tratar polimorficamente creando predicados iguales que utilicen todos los tipos de actividades.

2.:

seAchancho(Persona):-
actividad(Persona, _),
forall(actividad(Persona, Actividad), not(esFisico(Actividad))).

esFisico(deporte(Nombre)):-
actividad(_, deporte(Nombre)).
esFisico(subirEscaleras(Pisos)):-
actividad(_ , subirEscaleras(Pisos)),
Pisos > 4.

De esta manera implementamos el concepto de polimorfismo con "esFisico" y además creamos una solución más simple y declarativa que solo verifica lo que pide el enunciado "que ninguna actividad sea física".

Man, tenes varias cosas mal: te nombro algunas porque el cel no me deja leer todo =P
La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista ==> Si es engorroso a la vista, son problemas de expresividad no de declaratividad.
Al final de todo veo que pusiste "Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta."
El findall NO es una función inversible, es parcialmente inversible y esto se logra únicamente instanciando previamente su variable central... en este caso seria "Persona", osea si queres convertir el predicado que te dan ellos en "inversible" seria así:

seAchancho(Persona):-
esPersona(Persona),
findall(Nombre, actividad(Persona,deporte(Nombre)), Nombre),
length(Nombre,0),
findall(Piso, (actividad(Persona, subirEscaleras(Piso)), Piso >4), Pisos),
length(Pisos,0).
esPersona(Persona):- actividad(Persona,_).
23-02-2017 14:28
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Leo13 Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 5
Agradecimientos dados: 40
Agradecimientos: 7 en 2 posts
Registro en: Dec 2014
Mensaje: #8
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
(23-02-2017 12:49)TomTom escribió:  Hola a todos, hice la Parte A, para discutir. Ahora voy a hacer los otros y también los posteo!

Parte A

Spoiler: Mostrar
1.:

Errores conceptuales:

Las variables están todas asignadas sin manera de hacerles un cambio, por lo que cada vez que se cree un objeto de la clase "futbolista", estos van a ser todos iguales. Debería agregarse un construct, y así cada vez que se crea un futbolista asignarle sus valores y habilidades propias.

Por el otro lado, "nivelGambetero" es una variable que está de más. El nivel de la habilidad debería saberlo cada habilidad.

La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista. No se hace uso de polimorfismo para tener un código más robusto, general y adaptable.

2.:

class futbolista {

var edad
var altura
var peso
var habilidades


constructor (unaEdad, unaAltura, unPeso, unasHabilidades){
edad = unaEdad
altura = unaAltura
peso = unPeso
habilidades = unasHabilidades
}
method peso(){
return peso
}
method altura(){
return altura
}
method edad(){
return edad
}

method puntaje(){
return habilidades.sum({habilidad => habilidad.puntajeUnico(self)})
}

}

class forzudo{

method puntajeUnico(jugador){
return jugador.peso() * jugador.altura()
}
}

class gambetero{

var nivelGambetero

construct(unNivel){
nivelGambetero = unNivel
}

method puntajeUnico(jugador){
return nivelGambetero / (jugador.peso() * jugador.altura())
}

class rapido{

method puntajeUnico(jugador){
return edad / (jugador.peso() * jugador.altura())
}

De esta manera, al crear al jugador podemos especificar todos sus atributos, y luego cada habilidad se encarga de calcular su propio puntaje según el jugador, siendo así un codigo más adaptable (ya que si quiero agregar más habilidades solo debo crear su respectiva clase y no hacer ningún tipo de modificación al resto del codigo) y más declarativo.

3.a:

La manera más facil de hacer esto es que se cree una variable "alturaCalculo" (var alturaCalculo = 1,70) y un setter y getter de esta, de esta manera si en algún momento esta debe ser cambiada, cabe la posibilidad de hacerlo sin ninguna modificación en el código.

3.b:

Siguiendo las modificaciones propuestas en el punto anterior, crearía una clase con un metodo "puntajeUnico" que calcule de manera especifica para cada nueva habilidad.

4:

Ayuda ya que si no se delegaría el calculo del puntaje de cada habilidad, cada vez que se agregue una deberían agregarse ifs, variables, y modificaciones que hacen el codigo poco declarativo, engorroso y cada vez menos modificable.


AGREGO LA PARTE C

Parte C
Spoiler: Mostrar
1.:


a. Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta.

b. Falso, la solución no es declarativa ya que se abusa el uso del findall, haciendola repetitiva, mas allá de que este sea un predicado de orden superior, generando una solución procedural.

c. Falso, se pueden tratar polimorficamente creando predicados iguales que utilicen todos los tipos de actividades.

2.:

seAchancho(Persona):-
actividad(Persona, _),
forall(actividad(Persona, Actividad), not(esFisico(Actividad))).

esFisico(deporte(Nombre)):-
actividad(_, deporte(Nombre)).
esFisico(subirEscaleras(Pisos)):-
actividad(_ , subirEscaleras(Pisos)),
Pisos > 4.

De esta manera implementamos el concepto de polimorfismo con "esFisico" y además creamos una solución más simple y declarativa que solo verifica lo que pide el enunciado "que ninguna actividad sea física".


"Errores conceptuales:
Las variables están todas asignadas sin manera de hacerles un cambio, por lo que cada vez que se cree un objeto de la clase "futbolista", estos van a ser todos iguales. Debería agregarse un construct, y así cada vez que se crea un futbolista asignarle sus valores y habilidades propias."

En serio consideras que eso es un error conceptual? Tan solo por eso te pueden decir que el A.1 no te lo van a considerar. El hecho de que no haya getters ni setters ni constructor es por cuestion de espacio, si los agregasen el final tendria 4 hojas de largo.
Errores conceptuales son: esta bien delegado? y la expresividad? y la declaratividad? ... Es decir involucra a todos los conceptos transversales y a los propios del paradigma thumbup3
23-02-2017 17:30
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
viktorxD Sin conexión
Profesor del Modulo A
Clases de ModuloB Analisis1
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 291
Agradecimientos dados: 68
Agradecimientos: 304 en 96 posts
Registro en: May 2013
Mensaje: #9
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Mi Parte B1 deberia estar toda bien, porque la parte B2 no la vi

Y la parte C

En esta foto mejore mi solución Parte C2, seguro fue por eso que me pusieron 4, había usado findall+forall
Andaba , pero quedaba más largo y feo...


Archivo(s) adjuntos Imagen(es)
               

(Este mensaje fue modificado por última vez en: 24-02-2017 00:55 por viktorxD.)
24-02-2017 00:26
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
viktorxD Sin conexión
Profesor del Modulo A
Clases de ModuloB Analisis1
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 291
Agradecimientos dados: 68
Agradecimientos: 304 en 96 posts
Registro en: May 2013
Mensaje: #10
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
(23-02-2017 14:28)Arito04 escribió:  
(23-02-2017 12:49)TomTom escribió:  Hola a todos, hice la Parte A, para discutir. Ahora voy a hacer los otros y también los posteo!

Parte A

Spoiler: Mostrar
1.:

Errores conceptuales:

Las variables están todas asignadas sin manera de hacerles un cambio, por lo que cada vez que se cree un objeto de la clase "futbolista", estos van a ser todos iguales. Debería agregarse un construct, y así cada vez que se crea un futbolista asignarle sus valores y habilidades propias.

Por el otro lado, "nivelGambetero" es una variable que está de más. El nivel de la habilidad debería saberlo cada habilidad.

La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista. No se hace uso de polimorfismo para tener un código más robusto, general y adaptable.

2.:

class futbolista {

var edad
var altura
var peso
var habilidades


constructor (unaEdad, unaAltura, unPeso, unasHabilidades){
edad = unaEdad
altura = unaAltura
peso = unPeso
habilidades = unasHabilidades
}
method peso(){
return peso
}
method altura(){
return altura
}
method edad(){
return edad
}

method puntaje(){
return habilidades.sum({habilidad => habilidad.puntajeUnico(self)})
}

}

class forzudo{

method puntajeUnico(jugador){
return jugador.peso() * jugador.altura()
}
}

class gambetero{

var nivelGambetero

construct(unNivel){
nivelGambetero = unNivel
}

method puntajeUnico(jugador){
return nivelGambetero / (jugador.peso() * jugador.altura())
}

class rapido{

method puntajeUnico(jugador){
return edad / (jugador.peso() * jugador.altura())
}

De esta manera, al crear al jugador podemos especificar todos sus atributos, y luego cada habilidad se encarga de calcular su propio puntaje según el jugador, siendo así un codigo más adaptable (ya que si quiero agregar más habilidades solo debo crear su respectiva clase y no hacer ningún tipo de modificación al resto del codigo) y más declarativo.

3.a:

La manera más facil de hacer esto es que se cree una variable "alturaCalculo" (var alturaCalculo = 1,70) y un setter y getter de esta, de esta manera si en algún momento esta debe ser cambiada, cabe la posibilidad de hacerlo sin ninguna modificación en el código.

3.b:

Siguiendo las modificaciones propuestas en el punto anterior, crearía una clase con un metodo "puntajeUnico" que calcule de manera especifica para cada nueva habilidad.

4:

Ayuda ya que si no se delegaría el calculo del puntaje de cada habilidad, cada vez que se agregue una deberían agregarse ifs, variables, y modificaciones que hacen el codigo poco declarativo, engorroso y cada vez menos modificable.


AGREGO LA PARTE C

Parte C
Spoiler: Mostrar
1.:


a. Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta.

b. Falso, la solución no es declarativa ya que se abusa el uso del findall, haciendola repetitiva, mas allá de que este sea un predicado de orden superior, generando una solución procedural.

c. Falso, se pueden tratar polimorficamente creando predicados iguales que utilicen todos los tipos de actividades.

2.:

seAchancho(Persona):-
actividad(Persona, _),
forall(actividad(Persona, Actividad), not(esFisico(Actividad))).

esFisico(deporte(Nombre)):-
actividad(_, deporte(Nombre)).
esFisico(subirEscaleras(Pisos)):-
actividad(_ , subirEscaleras(Pisos)),
Pisos > 4.

De esta manera implementamos el concepto de polimorfismo con "esFisico" y además creamos una solución más simple y declarativa que solo verifica lo que pide el enunciado "que ninguna actividad sea física".

Man, tenes varias cosas mal: te nombro algunas porque el cel no me deja leer todo =P
La manera de calcular el puntaje es muy poco declarativa con mucho uso del if y engorrosa a la vista ==> Si es engorroso a la vista, son problemas de expresividad no de declaratividad.
Al final de todo veo que pusiste "Verdadero, es inversible ya que el findall no necesita que se genere a la persona para funcionar de manera correcta."
El findall NO es una función inversible, es parcialmente inversible y esto se logra únicamente instanciando previamente su variable central... en este caso seria "Persona", osea si queres convertir el predicado que te dan ellos en "inversible" seria así:

seAchancho(Persona):-
esPersona(Persona),
findall(Nombre, actividad(Persona,deporte(Nombre)), Nombre),
length(Nombre,0),
findall(Piso, (actividad(Persona, subirEscaleras(Piso)), Piso >4), Pisos),
length(Pisos,0).
esPersona(Persona):- actividad(Persona,_).

No les gusta ver Findall a menos que no quede de otra.
En el curso de Verano repitieron muchas veces
Findall es de Putos

24-02-2017 14:25
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Giskard Sin conexión
Empleado del buffet
Soy una frase en italica
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 8
Agradecimientos dados: 0
Agradecimientos: 0 en 0 posts
Registro en: Feb 2016
Mensaje: #11
RE: [APORTE][FINAL [PDEP] Final de Paradigmas de Programación 18-02-2017
Subo mi resolución, me pareció bastante largo este final, espero que el de mañana sea menos jodido.
Tengo un par de dudas sobre todo en la parte de funcional, si alguno se copa a ayudarme bienvenido sea

1) Delegacion : La responsabilidad de calcular el puntaje es de cada habilidad, no
del futbolista.
Encapsulamiento : se rompe el encapsulamiento de las habilidades al acceder a su
funcionamiento interno.
Polimorfismo : No se hace uso de polimorfismo para preguntar a cada habilidad el puntaje,
esto no solo es engorroso a la vista sino que si necesitamos agregar o quitar habilidades
tenemos que modificar el metodo puntaje() agregando cada vez mas ifs

2)
class futbolista {
var edad = 18
var altura = 1.70
var peso = 60
var habilidades = []

method puntaje(){
var puntajeTotal = 0
habilidades.forEach({hab => puntajeTotal += hab.puntaje(self)})
return puntajeTotal
}

method edad(){
return edad
}

method peso(){
return peso
}

method altura(){
return altura
}
}


class Habilidad{
method puntaje(futbolista){
return futbolista.peso() * futbolista.altura()
}
}

class Gambetero inherits Habilidad{
var nivelGambetero
override method puntaje(futbolista){
return nivelGambetero / super(futbolista)
}
}

class Rapido inherits Habilidad{
override method puntaje(futbolista){
return futbolista.edad() / super(futbolista)
}
}

class Forzudo inherits Habilidad{

}

PARTE B
1)
a) Falso, se agrega una nueva funcion puntajePorHabilidad que reciba la habilidad
y el futbolista
b) Falso, tiene que tener la restriccion Fracitional porque en ("gambetero", nivel) se
usa la segunda componente nivel para dividirla
c) Falso, no se puede agregar porque necesitariamos una tupla de 3 elementos
y puntajePorHabilidad recibe una tupla de dos elementos, tampoco podemos agregar
una tupla en la segunda componente porque necesita recibir un Fractional a
d) Falso, se puede modelar, seria una funcion que reciba un futbolista y devuelva
un futbolista con un año incrementado.

2) Acá es donde tengo dudas, son muchas cosas diferentes que pide, no se si pide todo
por separado o una funcion que solucione todo, me confunde tambien que no se como resolver
el problema del 1.b de que "el tipo puede ser cualquier cosa", pero bueno yo hice esto :

data Persona = Persona {nombre :: String, edad :: Int, altura :: Float, peso :: Float}
data Futbolista = Futbolista {datos :: Persona, habilidad :: Habilidad}
data Habilidad = Gambetero Int | Forzudo | Rapido | Suertudo Float Float

puntaje (Futbolista datos (Gambetero nivel)) = nivel / edad datos - peso datos
puntaje (Futbolista datos (Forzudo)) = peso datos * altura datos
puntaje (Futbolista datos (Rapido)) = altura datos / peso datos
puntaje (Futbolista datos (Suertudo impacto probabilidad)) = --el calculo no esta especificado en el enunciado--

PARTE C
1)
a- Falso, si consulto con una variable no se va a ligar a ningun valor inicialmente, por
lo que el motor va a ligarla con todos los valores posibles que pueda tener segun el predicado
actividad.
b- Falso, utilizar predicados de orden superior no garantiza la declaratividad, la declaratividad
es plantear la solucion en función del "qué necesito obtener" y no de forma algoritmica en función del
"cómo hago o cómo son la serie de pasos para obtenerlo". La solución esta planteada de la segunda forma
por lo tanto no es declarativa.
c- Falso, se necesita delegar lo que queremos tratar a un predicado que reciba los
diferentes casos de functores para asi poder tratarlos de forma polimórfica.

2)
seAchancho(Persona):-
actividad(Persona,_),
forall(actividad(Persona, Actividad), not(actividadFisica(Actividad))).

actividadFisica(deporte(_)).
actividadFisica(subirEscaleras(Piso)):-
Piso > 4.
24-02-2017 17:31
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.