Problemilla interesante

[Windgate]

Lo he probado y sólo veo que cuenta y cuenta, es como un:

LOOP
   say ( x++ );
END

Llega a 250 y sigue, pero hay 150 soldados, mi no entendel ???

Pobre Hackzjuan, que no nos creemos que haya solución, qué malos que somos ;D

EDIT: Vale, ya ha terminado, veo que todos tienen el mismo turno, pero al lado sale el tiempo y hay 6 valores distintos... Al menos pone el mismo turno eso sí... Ah, vale, el tiempo ese es un timer, ok.

EDIT 2: Veo el código y veo la lógica, pero hay algo que no me convence, los soldados se comunican uno a uno, no va en paralelo, por tanto en una de las comunicaciones el último soldado podría dar a toda la fila la orden de disparar, la orden recorre la fila y en el siguiente FRAME disparan, vamos, que no me termina de convencer la solución (No estoy diciendo que esté mal, pero no me convence). ¿No hay algún link donde alguien explique el problema lujosamente con dibujos y cosas así? Es que soy un poco retarded y aquí no es que nos expliquemos muy bien en general :)

EDIT 3: Cagondio, ahora con 200 soldados me da error de ejecución y me terminan en turnos distintos algunos antes de reventar.

EDIT 4: Hay 8 variables privadas por soldado, suficientes para codificar el número de soldado hasta 256, tendría que funcionar para números mayores que 256 con el mismo número de variables.

Qué cabrón que soy, no te enfades Hackzjuan, no es que sea incrédulo, simplemente le estoy dando vueltas a tu "problemita interesante", está peludo xD

[HaCkZJuaNN]

Lo he probado y sólo veo que cuenta y cuenta, es como un:

LOOP
   say ( x++ );
END

Llega a 250 y sigue, pero hay 150 soldados, mi no entendel ???

Pobre Hackzjuan, que no nos creemos que haya solución, qué malos que somos ;D

EDIT: Vale, ya ha terminado, veo que todos tienen el mismo turno, pero al lado sale el tiempo y hay 6 valores distintos... Al menos pone el mismo turno eso sí... Ah, vale, el tiempo ese es un timer, ok.

EDIT 2: Veo el código y veo la lógica, pero hay algo que no me convence, los soldados se comunican uno a uno, no va en paralelo, por tanto en una de las comunicaciones el último soldado podría dar a toda la fila la orden de disparar, la orden recorre la fila y en el siguiente FRAME disparan, vamos, que no me termina de convencer la solución (No estoy diciendo que esté mal, pero no me convence). ¿No hay algún link donde alguien explique el problema lujosamente con dibujos y cosas así? Es que soy un poco retarded y aquí no es que nos expliquemos muy bien en general :)

EDIT 3: Cagondio, ahora con 200 soldados me da error de ejecución y me terminan en turnos distintos algunos antes de reventar.

EDIT 4: Hay 8 variables privadas por soldado, suficientes para codificar el número de soldado hasta 256, tendría que funcionar para números mayores que 256 con el mismo número de variables.

Qué cabrón que soy, no te enfades Hackzjuan, no es que sea incrédulo, simplemente le estoy dando vueltas a tu "problemita interesante", está peludo xD

Tengo que probar lo del 200. 200 es propiamente múltiplo de 8 así que debería funcionar...

Respecto a lo de que se comunique uno con todos, por eso divido en 4 frames y si te fijas las variables las tengo duplicadas, privadas y locales. Así estoy seguro de que se respeta eso. En la fase de "pensar" los soldados ÚNICA Y EXCLUSIVAMENTE UTILIZAN LAS VERSIONES PRIVADAS DE LAS VARIABLES. En la siguiente fase, cada soldado asigna cada salida privada a su versión pública, Y HAY UN FRAME JUSTAMENTE DESPUÉS DE ESTO, ASÍ QUE HASTA QUE NO TERMINAN DE HACER ESTO TODOS LOS SOLDADOS NO CONTINÚA. En la siguiente fase, cada soldado copia las salidas de los de sus lados en sus entradas, pero durante esta fase esas variables NO SE MODIFICAN, únicamente se asignan de uno a otro. Por último, en la última fase del turno, los soldados copian sus entradas públicas sobre sus entradas privadas, para poder trabajar con ellas. De este modo, si no te das cuenta, no hay posibilidad de que ocurra eso que dices, ya que siempre me aseguro de que todos los soldados hayan acabado con cada parte antes de empezar a mezclar las cosas.

Hay una ristra enorme de says comentada por ahí con todas las entradas/salidas. Descomentadla y descomentad también la parte del "while(!key(_enter)), etc..."(que está tanto en el main como en el proceso soldado, hay que descomentarlo 2 veces). Así es como lo debugeé y así podéis ver turno a turno que es lo que va haciendo cada soldado. Hasta que no le dáis a enter no pasa al siguiente turno. Así a lo mejor os queda más claro cómo funciona el algoritmo.

Efectivamente con 200 también peta, que raro... pero estoy del todo seguro de que tiene que ser un problema al escribirlo. Intentad entender la lógica del algoritmo y daros cuenta de que no hay lugar a fallo. No me apetece nada ponerme a rebuscar donde está el fallo en el programa. Si tuviera una pizarra os lo explicaría con dibujitos, pero me da pereza hacer los dibujitos en paint...

Estoy probando con 1000 para dejarte contento... pero fíjate en el código del procesos soldado y date cuenta de que EN NINGÚN MOMENTO UTILIZA LA CONSTANTE N DENTRO DEL CÓDIGO, y los únicos momentos en los que utiliza la variable num es para imprimir los resultados y para conseguir que el programa termine cuando ya hayan disparado, en cualquier otro momento, prescinde totalmente de esto y únicamente se comunica con su siguiente y con su anterior.

[HaCkZJuaNN]

Lo he probado y sólo veo que cuenta y cuenta, es como un:

LOOP
   say ( x++ );
END

Llega a 250 y sigue, pero hay 150 soldados, mi no entendel ???

Espero que hayas entendido que eso es porque si hay 150, deberá acabar más o menos en el 450... 3n.

[HaCkZJuaNN]

Probé con 1000 y tras casi 10 minutos en el turno 2992 dispararon los 1000 a la vez.

He probado el caso 17 a mano y funciona perfectamente, hay algún problema en el código con este caso, y eso afecta a todos los demás múltiplos de 8 más 1 o más 2. Pero como ya he dicho, no tengo ninguuuuuuuna gana de arreglarlo.

[SplinterGU]

el codigo es bastante largo como para con solo verlo leer claramente lo que quisiste hacer (o realmente no le dedique tiempo) ... no entiendo por que decis que se necesitan varias entradas y salidas por soldado, deberia haber 1 sola entrada y 1 sola salida por soldado, y lo de 4 frames no entiendo porque, deberia ser 1 solo frame... por que dice wind que hay un "x++" ? no es que los soldados no cuentan? (aclaro que no mire el codigo, demasiado largo)

si la solucion es correcta matematicamente debe funcionar en todos los casos, si no funciona y necesita parches para casos especificos, entonces a mi entender no es una solucion matematica...

por favor, no te lo tomes a mal, sabemos todos que eres un crack en las matematicas, pero danos la solucion real, publicada y oficial...

[SplinterGU]

ja! ya veo lo que hace... eso es totalmente trucho... asi no vale... ahora veo por que los 4 frames... no, esa solucion no sirve... la idea no es que cada 4 frames chequees si todos terminaron... ademas 4 frames te da tiempo que los soldados coincidan en 4 instancias de tiempo diferente... es como decir... disparen todos a la vez, pero la vez significa rangos de 4 horas...

perdon, pero la solucion asi no es solucion...

[HaCkZJuaNN]

ja! ya veo lo que hace... eso es totalmente trucho... asi no vale... ahora veo por que los 4 frames... no, esa solucion no sirve... la idea no es que cada 4 frames chequees si todos terminaron... ademas 4 frames te da tiempo que los soldados coincidan en 4 instancias de tiempo diferente... es como decir... disparen todos a la vez, pero la vez significa rangos de 4 horas...

perdon, pero la solucion asi no es solucion...

Splinter, empiezo a pensar seriamente que tienes algo en contra mío.

Lo de comprobar si ha terminado es para que el programa no siga corriendo eternamente. Quítalo y siguen disparando todos al mismo tiempo, solo que el programa sigue corriendo después de que hayan disparado.

Los 4 frames, como ya te he explicado 50 veces, son para que las entradas no se solapen con las salidas en el mismo turno. Es por el funcionamiento de bennu, si bennu fuera totalmente sincronizado(todos los procesos corrieran exactamente a la vez y las entradas y salidas fueran actualizadas únicamente al final de los turnos), no haría falta. Y todos terminan en la misma instancia de tiempo, porque el if de la condición de disparo está en el mismo sitio.

Lo del x++ es porque es la impresión que le dio cuando lo ejecutó. Hay un turno++ que sirve para contar los turnos y ver en qué turno disparan, pero eso es meramente para ver las entradas y salidas y comprobar que disparan a la vez, quítalo y seguirán disparando al mismo tiempo, excepto que no sabrás en qué turno es.

La solución es correcta, ahora mismo estoy 100% seguro, funciona en todos los casos, no necesita parches para casos específicos, no tiene ninguno. Ahora mismo falla en algunos casos muy concretos POR UN ERROR EN EL CÓDIGO ESCRITO EN BENNU, que no tengo ninguna gana de buscar porque parece sumamente complicado de encontrar, pero he probado esos casos que fallan haciendo el algoritmo manualmente y funciona perfectamente.

No hay una "solución real". Hay una "solución ÓPTIMA", que no me sé pero que utiliza funciones matemáticas y cosas de modo que en realidad no da el algoritmo, sino demuestra que se puede obtener un algoritmo que haga eso en 2n-2.

No sé si lo sabes pero en matemáticas incontables veces se puede demostrar que algo que cumple unas determinadas propiedades existe sin encontrarlo explícitamente. Creo que eso es lo que ocurre en este caso, la solución 2n-2 se demuestra que es posible obtenerla y que es la óptima, pero no se conoce realmente(al menos eso es lo que tengo entendido).

Por favor splinter, puedes dejar de tratar de demostrar que me equivoco??? Si no te apetece, no entiendas la solución, pero entonces no intentes demostrar que está mal sin entenderla... La solución se la comenté a un profesor de mi universidad dedicado a este tipo de temas y me dijo que era perfectamente correcta, pero que, obviamente, no era la mejor. Si tuviera una pizarra y estuviera en persona creo que sería bastante más fácil explicarosla, pero la solución estar está bien.

[DjSonyk]

Hombre yo no creo que Splinter tenga nada contra ti,y tampoco intenta demostrar que te equivocas,solo que no le convence o no le parece la solución correcta,aun asi yo he mirado por ahi en google y no sale nada respecto al problema del peloton aun asi si que he visto salidas/entradas de maquinas infinitas con muchas ecuacciones que no creo que sean la solución pero pienso que si realmente no existe la solicion real puede que pase como le paso a Arquitas de Tarento que trato de solucinar el problema de la duplicación del cubo : " Dado un cubo de arista conocida¿se puede multiplicar a esta por alguna fracción ,de modo que el volumen del cubo se duplique?" ,la respuesta hoy es evidente ,NO....Hay cosas que no se pueden conseguir ,aunque si como dices hay una optima ahora me pica la curiosidad de conocerla.....De todas formas me huele a una operación matematica-cientifica ,y como sabemos los cientificos ,primero plantean una teoria y luego intentan demostrarla,y hasta que no se demuestre..... pues eso.

[Windgate]

No HackzJuan, que no tenemos nada en contra tuyo hombre, es que estamos incrédulos ante semejante problema tranki ;)

Tú defiende tu postura ante Splinter que es muy "cabezota", a mí me ha quitado la razón miles de veces 8) pero no te enfades :P

Yo sigo pidiendo un link de wikipedia o similar, porque el código es complejo de entender... Mucho

[HaCkZJuaNN]

Hombre yo no creo que Splinter tenga nada contra ti,y tampoco intenta demostrar que te equivocas,solo que no le convence o no le parece la solución correcta,aun asi yo he mirado por ahi en google y no sale nada respecto al problema del peloton aun asi si que he visto salidas/entradas de maquinas infinitas con muchas ecuacciones que no creo que sean la solución pero pienso que si realmente no existe la solicion real puede que pase como le paso a Arquitas de Tarento que trato de solucinar el problema de la duplicación del cubo : " Dado un cubo de arista conocida¿se puede multiplicar a esta por alguna fracción ,de modo que el volumen del cubo se duplique?" ,la respuesta hoy es evidente ,NO....Hay cosas que no se pueden conseguir ,aunque si como dices hay una optima ahora me pica la curiosidad de conocerla.....De todas formas me huele a una operación matematica-cientifica ,y como sabemos los cientificos ,primero plantean una teoria y luego intentan demostrarla,y hasta que no se demuestre..... pues eso.

Ya he dicho que el problema está demostrado que existe una solución 2n-2 y está demostrado que es imposible encontrar una mejor(demostración matemática). Yo no conozco la solución, y me suena que la solución no se conoce, aunque se sabe que existe. Algo así. Como ya dije, matemáticamente es posible probar la existencia de algo sin conocerlo.

[HaCkZJuaNN]

No HackzJuan, que no tenemos nada en contra tuyo hombre, es que estamos incrédulos ante semejante problema tranki ;)

Tú defiende tu postura ante Splinter que es muy "cabezota", a mí me ha quitado la razón miles de veces 8) pero no te enfades :P

Yo sigo pidiendo un link de wikipedia o similar, porque el código es complejo de entender... Mucho

Lo he buscado pero no encuentro nada.

[DCelso]

A ver, dandole mucho al coco no hay forma de hacerlo sin que los soldados no tengan espacio para guardar el número de soldados que hay. A ver:
Una solucion: mandas una variable a 0 al último soldado, este la manda incrementada en 1 al siguiente, así uno a uno hasta el primero, este primero cuando la recibe la incrementa en uno y ya conoce el número exacto de soldados (N) y ahora inicia un contador para disparar después de N saltos, y manda N-1 al siguiente soldado, este iniciará un contador para disparar justo después de la variable pasada de saltos N-1, y la decrementa y la pasa al siguiente así hasta el último que recibirá un 0 y al siguiente golpe de reloj disparará y coinicidirá con todos para disparar.
Claro esta solucion supone que puedes guardar el número de soldados en una variable, así que si tienes una variable de 16 bits no podrás tener más de 65535 soldados, se produciría oveflow,
También supones que los soldados pueden decrementar en cada golpe de reloj una variable internta.

[HaCkZJuaNN]

También supones que los soldados pueden decrementar en cada golpe de reloj una variable internta.

Eso se puede hacer, lo otro no.

[DCelso]

Otra forma, todos los soldados tienen una variable, cuando ordendes disparar al último, manda su id cuo, y lo va pasando uno a uno encolando su id, cuando el primero reciba todos los ids, este empieza a mandar por otro lado uno a uno los ids encolados, cuando todas las variables de todos los soldados tengan su id igual a la variable disparan, mientras que el primero disparará cuando se vacíe su cola.
si se hizo bien todos los soldados deben recibir su id a la vez ya que lo encolaron en orden en la primera vuelta.
Esta solucion presupone que puedes mandar una variable de tipo cola (o lista) y que el primer soldado es un poco especial y sabe repartir ids los ids.
Tambien presupones que puedes tener variables capaces de guardar ids únicos.

[DCelso]

También supones que los soldados pueden decrementar en cada golpe de reloj una variable internta.

Eso se puede hacer, lo otro no.

Entonces es imposible, casi 100%
Por eso dije que faltan datos al enunciado.