Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
Consulta sobre final paradigmas 21/12/13
Autor Mensaje
greeksuspend21 Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 35
Agradecimientos dados: 8
Agradecimientos: 38 en 11 posts
Registro en: Dec 2013
Mensaje: #1
Consulta sobre final paradigmas 21/12/13 Finales Paradigmas de Programación
Buenas, estoy con una duda de un final de paradigmas, el link es el siguiente:

https://docs.google.com/document/d/1sl2u...41NW4M/pub

en el ejercicio 2C), cuando pide cambiar las funciones para meter nuevas ruedas con distintos premios, como sería la resolución para haskell??
Se me ocurre que podría ser simplemente agregar datos para nuevas ruedas del tipo
premiar 1 rueda2 (dinero, items) = ...
premiar 2 rueda2 (dinero, items) = ...
etc... pero no creo que sea la solución correcta. Uds como lo harían?

Probablemente habria que cambiar la dupla (costo,premio) de la rueda por (numeroRueda,costo,premio) asi ruedas con el mismo costo y los mismos premios pueden diferenciarse..., pero salvo eso no se me ocurre nada mas.
(Este mensaje fue modificado por última vez en: 28-02-2014 02:09 por greeksuspend21.)
28-02-2014 02:02
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
reLlene Sin conexión
Profesor del Modulo A
...
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 307
Agradecimientos dados: 371
Agradecimientos: 63 en 35 posts
Registro en: Aug 2012
Mensaje: #2
RE: Consulta sobre final paradigmas 21/12/13
EJERCICIO 2
a) Criticar la solución en términos de delegación y repetición de lógica.
En términos de delegacion, no se cumple puesto que el comportamiento que debe tener la persona respecto de almacenar un premio, por ejemplo NO deberia de hacerse en la implementacion del objeto rueda sino mostrarse encapsulado en la clase que correspode (PERSONA)
Existe repetición de lógica en la implementacion del metodo girarPara: , alli donde se podria tener en cuenta al dinero de la persona como una variable local del metodo.
--
¿La solución propuesta funciona correctamente? Justificar.
A mi modo de ver, sigue funcionando excepto que no me cierra si corresponde hacer el mismo calculo que se hace en la implementacion de la solucion de objetos cuando pone unaPersona dinero: unaPersona dinero - costo. y hacer uso de las funciones costo y premio (de haskell)
Explicar ventajas y desventajas del uso de pattern matching en la función premiar.
Nos permite matchear por alguno de los patrones definidos y en caso de no coincidir con alguno de estos, no hacer nada!! (?
Comparar las dos implementaciones dadas en términos de efecto colateral y transparencia referencial.
En la primera solucion (objetos) hay asignación destructiva (al actualizar la variable local numero) pero NO efecto colateral, ya que a "grueso modo" el programa no sufre ningun cambio de estado con esta asignación. La transparencia ref es propia de la 2da solución, donde la dupla resultante esta unívocamente relacionada con los elementos de entrada, a la hora de matchear.
c) El éxito de la rueda de la fortuna llevó al sitio a querer tener otras ruedas del mismo estilo pero con distintos premios. Cada rueda debe poder tener distinta cantidad de casilleros, no necesariamente 6 como la que ya existe.
Proponer una alternativa de solución para cada implementación existente que contemple esto, de modo que se puedan tener nuevas ruedas con otros premios sin requerir cambios a la lógica del programa.

Se podria escribir un metodo llamado GirarPara:unaPersonaConCasilleros:unaCant y los premios tratarse de una coleccion de objetos.
En tanto que la solucion funcional podria seguir presentando su lista de items (mas de un premio) y la cantidad de casilleros estara determinada por la cantidad de patrones con los que cuente la funcion premiar (aunque dudo que sea lo que piden)

...
Ahora...ALGUIEN sabe como resolver el 1.d) ?? Sobre todo el tratado que se tiene que hacer sobre los relojes sacando provecho del polimorfismo, tenia un ejemplo de esto pero no lo encuentro y no me sale Confused
(Este mensaje fue modificado por última vez en: 28-02-2014 21:20 por reLlene.)
28-02-2014 21:07
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Cloud Sin conexión
Empleado de Fotocopiadora
A punto de estallar.
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 42
Agradecimientos dados: 7
Agradecimientos: 7 en 5 posts
Registro en: May 2011
Mensaje: #3
RE: Consulta sobre final paradigmas 21/12/13
(28-02-2014 21:07)reLlene escribió:  Ahora...ALGUIEN sabe como resolver el 1.d) ?? Sobre todo el tratado que se tiene que hacer sobre los relojes sacando provecho del polimorfismo, tenia un ejemplo de esto pero no lo encuentro y no me sale Confused

Primero, algo feo que se puede hacer para Fixear el problema de los puntos anteriores es agregar las reglas de "mecanismos", osea .


mecanismo(pila).
mecanismo(cuerda).
mecanismo(arena).


Se puede hacer "mejor", armando una lista sin repeticion de los mecanismos segun el pattern de fábrica, pero es un bardo y no es lo que sugerian en el final, simplemente enumerar los 3 y listo (estuve en la correccion).

Creo que apunta el D. a polimorfismo y pattern matching.

Te doy dos posibilidades que probé, una mas sencilla y otra más linda pero más larga.

la más larga:


%fabrica(pais, reloj)
fabrica(argentina, reloj(pila, analogico, pulsera)).
fabrica(egipto , reloj(pila, digital, pared)).
fabrica(suiza , reloj(cuerda, pulsera)).
fabrica(brasil , reloj(cuerda, pared)).
fabrica(suiza , reloj(pila, analogico)).
fabrica(argentina , reloj(pila, digital)).
fabrica(egipto , reloj(arena)).

%-----------------------------------
mecanismo(pila).
mecanismo(cuerda).
mecanismo(arena).
%-----------------------------------

%Para conocer la cantidad de relojes que funcionan bajo un mecanismo en particular
%alguien planteo lo siguiente:


esFabricado(R):-
fabrica(_, R).

usaMecanismo(M,R):-
mecanismo(M),
esFabricado(R),
R = reloj(M).
usaMecanismo(M,R):-
mecanismo(M),
esFabricado(R),
R = reloj(M,_).
usaMecanismo(M,R):-
mecanismo(M),
esFabricado(R),
R = reloj(M,_,_).

cantidad(X, C):-
mecanismo(X),
findall(X, fabrica(_, reloj(X)), L) , length(L, C).
cantidad(X, C):-
mecanismo(X),
findall(X, fabrica(_, reloj(X,_)), L) , length(L, C).
cantidad(X, C):-
mecanismo(X),
findall(X, fabrica(_, reloj(X,_, _)), L) , length(L, C).

cantidadPM(X,C):-
mecanismo(X),
findall(R, usaMecanismo(X,R), L) , length(L, C).


Que agrega el predicado "usaMecanismo\2" que está hecho inversible aunque podía dejarse no inversible si nunca lo usas directamente.
Lo que tiene de "lindo" es que por mecanismo obtenes las tuplas de relojes y cuando contas la cantidad en realidad tenes una lista de tuplas a contar.

La otra opcion es más simple (pongo solo la ultima parte):


usaMecanismo(M):-
fabrica(_, reloj(M)).
usaMecanismo(M):-
fabrica(_, reloj(M,_)).
usaMecanismo(M):-
fabrica(_, reloj(M,_,_)).

cantidadPM(X,C):-
mecanismo(X),
findall(X, usaMecanismo(X), L) , length(L, C).




Que cuando llamás al predicado CantidadPM devuelve exactamente lo mismo:

M = pila,
C = 4 ;
M = cuerda,
C = 2 ;
M = arena,
C = 1.

Pero los predicados auxiliares que agregué no hacen nada útil de por si, y no son inversibles, haces:
usaMecanismo(pila).

y te devuelve:
pila,pila,pila,pila.

Que te sirve para contar, porque al fin y al cabo es 4 veces pila... pero el resultado de la lista del findall no sirve para nada más que su length.
(Este mensaje fue modificado por última vez en: 28-02-2014 23:25 por Cloud.)
28-02-2014 23:24
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)