programancia101 - Todos los comentarios

re: a veces, las cosas cambian

phobeo — Wed, 24 Oct 2007 12:22:32 GMT

hola pirsonas!

Ante todo, mil perdones! Como he puesto en el articulo, pegue la version del codigo que no era! (los problemas de tener que exportar a html desde fuera en vez de con la herramienta del community server) }:/

Lo que pretendia que se viera en este trozo de codigo es un antipatron que he visto en un par de codigos reales: el problema de las referencias externas y las invariantes. Espero que con esta nueva version quede mas claro

Basicamente, teneis todos razon. Al tener una referencia externa y cambiarla, cambiamos el estado interno de los otros objetos. Esto es un fallo normal en programadores que no recuerdan que al asignar una referencia no COPIAS el objeto, solo apuntas a esa instancia. El problema surge cuando a veces queremos garantizar algun tipo de invariante (como en el caso de ser una HardRockStar, que solo debe gustarte el rock, el alcohol y las malas mujeres). El no guardar el estado despues de chequear la invariante (eg: clonando el objeto) hace que una referencia externa pueda dejarnos en un estado inconsistente (que es como te quedas despues de ver a Slash tocando un solo con Marta Sanchez, inconsistente)

re: a veces, las cosas cambian

suge — Tue, 23 Oct 2007 17:26:44 GMT

Estamos entonces todos deacuerdo??. No se que implicaciones malevolas tendrá el que la clase Style se encuentre dentro de Music Start. Pero vamos por lo que veo solo se crea una instancia de Style que es referenciada desde las tres instancias de "MusicStar".

Me estoy perdiendo algo, pero bueno el compilador dirá.

SaludOs.

re: a veces, las cosas cambian

penyaskito — Tue, 23 Oct 2007 14:30:27 GMT

El título del post lo dice todo :-P

re: a veces, las cosas cambian

Luis Ruiz Pavón — Tue, 23 Oct 2007 10:38:21 GMT

Sí, estoy con Tio Luiso XD y además el sercreo de Telepizza está en la masa...

Salu2

re: a veces, las cosas cambian

Augusto Ruiz — Tue, 23 Oct 2007 08:17:03 GMT

Tio Luiso está en lo cierto. Estamos cambiando el valor a la misma instancia de Style, que comparten todos.

re: a veces, las cosas cambian

Tio_Luiso — Tue, 23 Oct 2007 07:19:15 GMT

Hay trampa?

Desde aquí parece que las 3 instancias de MusicStar en realidad comparten una sola instancia de Style como su propiedad Style, que es la que se instanció antes de Slash, se le cambió el nombre también antes de Slash, y luego se le volvió a cambiar el nombre antes de paulina y marta.

En consecuencia, la salida debería ser:

nuestras estrellas de esta noche son:

nombre: Slash (estilo:CutrePop)

nombre: Paulina Rubio (estilo:CutrePop)

nombre: Marta Sanchez (estilo:CutrePop)

Eso es lo que pienso. Ahora voy a comprobarlo. Las preguntas son:

- Tendré Razón?

- Te perdonará Slash?

- Cuál es el secreto de Telepizza?

re: a veces, las cosas cambian

Eber Irigoyen — Mon, 22 Oct 2007 22:15:27 GMT

todos los objetos MusicStar tienen una referencia al unico objeto MusicStar.Style style, asi que todos mostraran estilo CutrePop

re: a veces, las cosas cambian

Serabe — Mon, 22 Oct 2007 21:06:18 GMT

Juraría que:

nuestras estrellas de esta noche son:

nombre: Slash (estilo: CutrePop)

nombre: Paulina Rubio (estilo: CutrePop)

nombre: Marta Sánchez (estilo: CutrePop)

Y si no me equivoco se debe a que todos guardan una referencia al mismo objeto style, al cual le has cambiado el nombre...

Si te soy sincero ahora mismo no sé si tengo razón porque la tengo, o porque estoy que me caigo por los suelos...

re: a veces, las cosas cambian

El Bruno — Mon, 22 Oct 2007 20:17:46 GMT

Ricardo pufff ... me has hecho pasar completamente del problema planteado (sorry); desp de ver de nuevo al gigante de Slash, estoy desempolvando unos CDs donde se desataba junto a Gilby Clark y otros ... basta de código por esta semana y a retomar la Gibson :D

a veces, las cosas cambian

programancia101 — Mon, 22 Oct 2007 18:14:25 GMT

Esta semana estaré de reunión en Santiago de Chile, preparando la próxima edición de IEEEXtreme , el

re: todos por igual

phobeo — Mon, 22 Oct 2007 17:36:10 GMT

suge: Efectivamente, es una solucion! }:)

Sin embargo, yo lo refactorizaria un poco para que las condiciones "similares" (por ejemplo: cuando insertamos en el array) se hagan en el mismo bloque de codigo. Suele ser buena idea cuando hay multiples posibilidades de ejecutar la misma accion en un trozo de codigo por si en el futuro añades/eliminas condiciones y lo hace mas legible

Tio_Luiso: Efectivamente, la solucion de suge se ajusta a lo que comentabamos... y no, no hace falta que hagas los calculos en un comment! }:)

re: todos por igual

Tio_Luiso — Mon, 22 Oct 2007 13:39:24 GMT

Ya he visto mi error. Lo que propone suge (a falta de revisar el código, cosa que no he hecho) me parece que está bien.

He hecho unos calculillos para ver si pa probabilidad de aparición de cada elemento en la muestra es la misma (la definición de equiprobabilidad), y lo es. He calculado la probabilidad que tiene cualquier elemento de entrar "inicialmente" en el array, y la probabilidad que tiene cualquier elemento posterior de entrar pisándolo (condicionado a que haya entrado previamente el elemento en el que estamos interesados). La resta de estas dos probabilidades tiene que ser una constante para todos los elementos. De hecho, tiene que acabar siendo igual a TamK / TamN para todos los elementos de N.

Si no hace falta que haga aquí los cálculos, mejor.

re: todos por igual

suge — Mon, 22 Oct 2007 08:05:05 GMT

Ahí va en C#. Quedaría algo más o menos así:

public static int[] arrayEquiprobable(myStream flujo_de_entrada, int long_array)

{

int posicionEstudiada = 0;

int[] array_solucion = new int[long_array];

Random miRandom =new Random(DateTime.Now.Millisecond);

int posAleatoria ;

while(flujo_de_entrada.hasNext())

{

if (posicionEstudiada<long_array)

{

array_solucion[posicionEstudiada]=flujo_de_entrada.getNext();

}

else

{

posAleatoria=miRandom.Next(posicionEstudiada);

if (posAleatoria<long_array)

array_solucion[posicionEstudiada]=flujo_de_entrada.getNext();

else

flujo_de_entrada.getNext();

}

posicionEstudiada++;

}

if (posicionEstudiada < long_array)

{

throw (new Exception("La longitud propuesta de la solución es" +

"mayor que el tamaño del stream.Situación no valida"));

}

return array_solucion;

}

Lo he dejado sin comentarios pero creo que se sigue bien.

SaludOs.

re: todos por igual

phobeo — Sat, 20 Oct 2007 11:58:08 GMT

suge: Hey! De sentirlo nada! Lo importante es ir proponiendo soluciones y ver como se ajustan o no (estamos aqui para "formarnos mentalmente" y no tanto para "dar con la solucion correcta", eso lo dejamos para el trabajo };D)

Como ya comente, creo que puedes cambiar la solucion que proponias... aunque claro, requiere ir haciendo recorridos para actualizar los valores de tu tabla cada vez. Sin embargo, la solucion que acabas de proponer parece mas sencilla... y usa memoria constante (solo necesita un contador y el generador de numeros aleatorios)... a mi me gusta! }:)

Te animas a mandar codigo para esa solucion? }:)

serabe: Si, puedes usar mas memoria, of course. Pero como ya deje caer antes (y ya alguien se dio cuenta)... puede hacerse con muy poquita memoria extra! };)

re: todos por igual

Serabe — Fri, 19 Oct 2007 11:38:43 GMT

Para resolver tu duda necesito hacer una pregunta... ¿puedo tener más variables a parte del n y del array?

re: todos por igual

suge. — Fri, 19 Oct 2007 10:54:18 GMT

Gracias por la bienvenida. Y lo siento por la cagada :-). Mira que no tener en cuenta el que un numero pudiera aparecer en la salida un número de veces mayor que el número de veces que aparece en la entrada !!!.

Grácias por la atención. Creo que tendré que revisar los planteamientos porque si lo mantengo más o menos igual y repito el sorteo en caso de que el valor que salga haya alcanzado su numero máximo de apariciones , y haciendo una traza sencilla, veo que no cumplo la equiprobabilidad. Lo pienso mejor.

De todas formas e tenido intuición (digo intuición por que ahora me faltan matematicas para poder comprobarlo), y solo lo he probado haciendome una traza a mano y parece que no va mal. A ver que te parece:

Leemos el primer elemento y lo metemos en la primera posición del array, leemos el segundo y a la segunda y así hasta llenarlo (los k primeros). Una vez que lo tenemos ahí leemos el siguiente k+1. Calculamos un entero aleatorio(lo llamo j) entre 1 (supongo arrays con posición inicial 1) y k+1 ; si es menor o igual que k (j<=k) colocamos el elemento en la posición j del array , si no seguimos con el siguiente elemento .Calculamos un aleatorio entre 1 y k+2; si es menor que k a la posición correspondiente del array , si no seguimos con el siguiente, …. Y así hasta el elemento N.

¿Qué tal suena?.

re: todos por igual

Tio_Luiso — Fri, 19 Oct 2007 08:20:24 GMT

Me parece (seguramente me equivoco) que a menos que conozca el tamaño de N, la muestra que tome no será equiprobable. Al menos siguiendo mi aproximación.

Si conozco el tamaño de N, podría tomar K enteros aleatorios desde 0 hasta el tamaño de N menos uno (sin repetición), y obtener los K elementos de N con un solo recorrido.

Si no conozco el tamaño de N, puedo acotar N diciendo que es como poco igual de grande que K y obtener los K elementos de este subconjunto de N. Pero estaríamos despreciando los elementos del resto de N, y por lo tanto, la muestra no sería equiprobable. De hecho, ocurrirá lo mismo con cualquier límite arbitrario que establezca para los números aleatorios, a menos que este límite sea exactamente el tamaño de N, en cuyo caso, los números aleatorios que obtengamos serán elementos equiprobablemente aleatorios de N. ¿No?

Obviamente me estoy confundiendo en algún punto.

re: todos por igual

phobeo — Thu, 18 Oct 2007 17:49:35 GMT

buenas! perdon por el retraso en responder, llevo ayer y hoy de viajes y sin conexion!

serabe: tu primera idea ya has visto que no funcionaria porque no respeta lo que comentabamos de la equiprobabilidad. Tu segunda aproximacion entiendo que es coleccionar los pares de (valor - numero de apariciones) de forma similar a como sugiere despues suge (ver comentario mas abajo) pero lo que no me queda claro es que harias luego con ellos, ni por que solo guardas m/2 valores. Puedes dar mas detalles?

Tio_Luiso: jejeje... como siempre muy avispado! Efectivamente, si tuvieramos un array o un metodo Reset() para volver atras, seria mucho mas facil... pero no los tenemos... aunque los comentarios que dejas son muy buenos como "pista" };D

Como comentas justo despues... si lo volcamos todo a una lista, tendriamos la posibilidad de hacer lo que dijiste en el primer comentario pero... la cuestion es: hace falta? Dejo una pista debajo del comentario, por si quieres leerla

suge: Bienvenido! Si, aceptamos pseudocodigo, C#, Java, Ruby... incluso Visual Basic! La mayoria de problemas son mas para "investigar" algo que para explicar "caracteristicas" de lenguajes... aunque tambien dejaremos caer alguno mas especifico }:)

En cuanto a tu solucion: efectivamente, podria funcionar, pero necesitaria una pequeña modificacion: Imagina el caso del flujo que mencionabamos que tenia un dos por cada cuatro unos. En este caso, tu estructura de sorteo quedaria como:

valor: 1 extremo: 7

valor: 2 extremo: 9

Peeeeero que pasaria si las 5 veces nuestra funcion aleatoria devuelve un 8? (puede pasar, es una funcion aleatoria) No existe niguna posibilidad de que una muestra tenga mas instancias de un elemento (doses, en este caso) que las que tenemos en el flujo.

A mi se me ocurren dos formas de modificar tu algoritmo para que funcione correctamente. Si te animas a buscarlas, podrias intentar despues buscar otra solucion "sin almacenar tantos datos" };)

Y por ultimo, como dije antes, voy a dejar otra pista por si alguien de los que "casi" lo tiene se anima a dar una solucion aun mas optima... no leais si quereis hacerlo sin pistas!

pista:

Con los comentarios que han dado, podeis dar una solucion que usa memoria constante, no importa lo grande que sea N

re: todos por igual

suge — Thu, 18 Oct 2007 13:59:00 GMT

Hola. Soy nuevo en esto y no se si tendría que ponerlo en pseudocodigo o no. Lo pongo en literatura y si hace falta lo codifico cuando tenga un rato. Como lo veo sería algo así :

Vamos rellenando una lista de duplas, con los valores que van saliendo y su número de apariciones. Supongamos que nos queda una lista como la siguiente:

Valores Apariciones

--------------------------

3 5

12 1

6 4

7 3

1 1

Una vez terminada la lista (terminada la lectura de los k valores), la recorremos cambiando el valor apariciones por la suma de las anteriores -1 (esto último es por cómo hacemos luego el sorteo). Tendríamos algo como

Valores ExtremoSup

-------------------------

3 4

12 5

6 9

7 12

1 13

Cuando estamos en este punto ya solo nos queda hacer un “sorteo” con N valores “premiados. Es decir un bucle for de 0 a N-1 con un randomize que nos de valores enteros entre 0 y K-1, y cada valor aleatorio se compara con los llamados Extremos superiores de la lista por orden ; si es menor o igual que el valor con que se compara ya tenemos el elemento equi-probable para la posición N del array solución, si no comparamos con el siguiente.

re: todos por igual

Tio_Luiso — Thu, 18 Oct 2007 13:17:06 GMT

Me contesto yo solo:

Basándome en lo que he propuesto, para que la muestra tomada fuera realmente equiprobable, el generador de enteros aleatorios tendría que devolver idealmente un entero aleatorio entre 1 y el tamaño de N. Si fuera menor, creo que la muestra no sería equiprobable. Y si fuera mayor, creo que tampoco.

¿Me equivoco mucho?

Siempre nos queda la solución cutre: Nos volcamos todo N en una estructura de acceso aleatorio, con lo cual, ya tendríamos 2 cosas: 1.- poder acceder al elemento que queramos y 2.- Conocer el tamaño de N.