¿Describir situaciones y el cómo se llega a ellas?

[Tachikomaia]

Tengo curiosidad por esto, que además pensé que se podría hacer con una base de datos estilo excel pero lo he pensado y no he visto cómo.

Mi forma era en archivos llamados
Variable1_Variable2_Variable3_etc.txt
conteniendo cada uno:
Variable1_Variable2_etc_Acción

Cada variable sustituída por el valor correspondiente, y lo mismo Acción.

Un ejemplo:
El archivo O_X_X_X_X_O_O_z_z_O.txt
contiene O_z_X_X_X_O_O_z_z_X_2

O sea, el archivo, en su nombre, marca esta situación de Tateti:
O_X_X
X_X_O
O_z_z
Turno de O
...donde z es casillero vacío.

Y el contenido de dicho archivo marca la situación anterior y qué acción se hizo en ella:
O_z_X
X_X_O
O_z_z
Turno de X
Acción 2 (o sea poner una X en el casillero superior vacío; el conteo o numeración de los casilleros es como se lee un texto cualquiera, de izquierda a derecha y bajando).

Es posible variar esto de muchas formas, por ejemplo contar verticalmente o hacer una síntesis con la cual se puede describir la situación simplemente con 1 variable. El problema de eso último es que, por lo que sé (me refiero a que quizá hay una forma más sencilla, pero no lo sé), requiere hacer algunos cálculos cada vez que se carga la variable, y sólo sirve si los rangos son limitados.

El tema es que dicha forma me ha dado demasiadas complicaciones para mi gusto, al menos con la herramienta que solía usar. Sí, probaré otra, pero como decía al principio tengo curiosidad por si se puede o no hacer esto, con una base de datos es estilo excel o sin archivos externos (es decir, usar variables nada más). Es que además, si no se puede con una base de datos estilo Excel, en el tema donde pedí otra herramienta debo decir que ese método no me serviría.

En principio se me ocurrió definir variables con estos nombres:
O_X_X_X_X_O_O_z_z_O_V1
O_X_X_X_X_O_O_z_z_O_V2
etc
O_X_X_X_X_O_O_z_z_O_Act
...
O sea, primero todo lo que sería el nombre del archivo (la descripción de una situación), y al final una de las variables que describen la situación anterior o la acción que la transformó en la otra.

El problema de esto es bastante evidente: El nombre de las variables es muy largo. En este caso se puede reducir porque se sabe que siempre cada variable es 1 caracter:
OXXXXOOzzO1
OXXXXOOzzO2
etc
Pero es evidente que hay problemas con más variables y que eso de quitar los _ no puede hacerse siempre, creo.

Entonces ¿de qué otra forma puede describir situaciones y el cómo se llega a ellas?

Gracias.

Por cierto acabo de pensar que quizá existan bases de datos que no sean estilo Excel. En mi herramienta es posible crear objetos con nombre a elección y ponerles variables dentro, lo cual creo que sería como "una base de datos que no es estilo Excel". Me serviría de no ser porque también tiene el problema de los nombres largos. Los archivos que mencioné al principio también podían tener nombres largos, pero eso me parecía bastante normal, que lo tengan variables u objetos no.

[Malenko]

Solo por comentar, pero Excel no es una base de datos, es una hoja de cálculo....

[Kritik]

Con lenguaje XML se puede crear una base de datos. Luego con un programa tipo Access puedes coger todos los datos del XML e importarlos a una base de datos con formato mdb, o accdb que son las usadas por Access, pero si no, igual la puedes dejar en XML.

El lenguaje de XML es un lenguaje que se escribe en archivos de texto plano. Por lo tanto, si tu herramienta te permite crear archivos de texto, solo tienes que ponerles la extensión XML. O incluso sin ella, con extensión txt de texto podrías tener los datos organizados, tal y como manda el formato XML.

Iniciado por Tachikomaia

Entonces ¿de qué otra forma puede describir situaciones y el cómo se llega a ellas?

Tienes un problema con la abstracción de tu programa. No estás abstrayendo de forma correcta el problema.

Yo hace tiempo hice este mismo juego. Los nombres de las variables no deben de almacenar el dato, sino que deben de ser nombres identificativos sobre el dato que contienen.

Es como si escribes un libro entero, y en vez de meterlo en el interior de un archivo de texto, lo que haces es dejar el archivo de texto vacio y como nombre del archivo le pones todo el texto del libro. No es la forma en la que debes de hacerlo. Pues lo mismo con las variables.

[Tachikomaia]

Para mí base de datos en informática sería un archivo o conjunto de archivos contenedores de datos que son usados para realizar acciones. Si me pongo flexible, diría que un conjunto de variables en un programa puede ser una base de datos, pero en general considero que la BD debe ser externa. Y bueno, el formato que he usado, con Clipper, era similar al de Excel, quizá el nombre técnico es matriz pero no lo tengo claro y le digo filas y columnas...
Por ahí un archivo Excel no es una BD porque -un suponer- no es algo a lo que otro programa acceda a usar sus datos, Access es más común ¿no? Pero Excel está medio ahí, porque bien que se pueden poner datos en un archivo de tal tipo y usarse, aunque sea manualmente.

Si hay un concepto más técnico o algo trataré de no usar dicha expresión como suelo usarla, es decir, en este sentido creo que no discutiré.

[Kritik]

Un motor de base de datos está diseñado para poder acceder de manera rápida a una gran cantidad de datos.

Pongamos como ejemplo los siguientes datos:
Habitación || Nº Enchufes || Bombillas
Comedor || 4 || 2
Baño || 1 || 5
Cocina || 4 || 1
Dormitorio || 2 || 2

Entonces, si no vas a tener más datos... puedes escoger un orden y ponerlos, por ejemplo, de la siguiente manera en un único archivo:

Comedor
Baño
Cocina
Dormitorio
4
1
4
2
2
5
1
2

Y podrás acceder de manera lo suficientemente rápida a los datos, porque aunque no está optimizada la manera de organizar los datos, llevan un cierto orden... lo suficiente para que sea eficiente con pocos datos.

Ahora bien, si los datos a introducir con este sistema convierten este sistema en uno que tenga miles y miles de líneas seguramente este sistema de organizar los datos ya no te sea eficiente, por lo que se tarde en recuperar los datos que quieras.

[agleiva]

Iniciado por Tachikomaia

Para mí base de datos en informática sería un archivo o conjunto de archivos contenedores de datos que son usados para realizar acciones. Si me pongo flexible, diría que un conjunto de variables en un programa puede ser una base de datos

En general cuando se habla de "base de datos" en el contexto del Desarrollo de Software, uno hace referencia a un RDBMS, o alternativamente un Key/Value store, no un "archivo" ni variables sueltas en el código, ni ninguna cosa por el estilo.

Vayámos acostumbrándonos a usar la terminología correspondiente...

[Tachikomaia]

Kritik:
En general, lamentablemente, no te entendí. Hace tiempo cuando no tenía Internet leí sobre los XML o algo parecido, y no lo entendí. Si hubiera podido preguntar, lo habría hecho, pero como encontré una alternativa, el tiempo pasó y... bueno, quizá más adelante reintente entender sobre los XML.

En cuanto a:
"Yo hace tiempo hice este mismo juego."
Ten en cuenta que esto no es "el juego", el Tateti fue un ejemplo, en realidad es un programa que resuelva problemas pero que por ahora son más sencillos que el TTT...
Su método para hallar soluciones implica memorizar situaciones a las que haya llegado y cómo llegó. Digamos que llega a la situación
OOX
zXX
OzX
En ese momento, debe ver qué acción realizó antes ¿cómo puede verlo? Una forma es tener memorizadas (en variables, internamente) todas las acciones que haya realizado hasta ahora, desde ciertos puntos en que resetea. Pero yo no lo hago así. ... Quizá cuando empecé no me di cuenta de esa forma o pensé que era inadecuada por algún motivo, la voy a probar a ver.
En mi método lo que hago es cargar datos de la situación actual (los datos en cuestión son sobre su pasado o causa: Cómo era la situación antes y qué se hizo en ella). Entonces ¿cómo puedo cargar dichos datos sin nombrar a la situación actual y tenerlos relacionados con dicha situación? ¿me explico? ¿puedes dar un ejemplo?

[Tachikomaia]

Creo que ya recuerdo por qué usé ese método. Es que antes no buscaba cómo llegar a una situación sino qué acción convenía hacer en cada situación posible del problema.

[Kritik]

La situación final de un proceso y como se llega hasta él sirve única y exclusivamente para ese proceso. Y por tanto necesita un código único y exclusivo para manejar esa información.

Por ejemplo, para reproducir una partida de ttt a partir de cierto punto (y dada su simplicidad podría ser desde el principio) y así asegurar resolver bien el problema puedes tener todos los resultados finales posibles, y el como se llega hasta ellos almacenados. Pero para llegar después a reproducir eso, y que los datos sirvan para algo más que para consulta necesitas un código que sirva única y exclusivamente para ese problema.

Yo quiero ir desde Madrid a París en bicicleta. Por lo tanto cojo el itinerario de alguien que ya llegó a París, y lo reproduzco. El día 1 hago noche en no se qué sitio. El dia 2 paso por estos sitios y hago noche en X sitio.

Sin embargo... ese itinerario y esa información me es totalmente inútil si lo que quiero es ir de Buenos Aires a Rio de Janeiro en bicicleta. Y este nuevo trayecto, esta nueva problemática necesita de programa específico que única y exclusivamente sirva para dicha problemática.

Ahora bien, si lo que quieres es coger cualquier tipo de información y guardarla, aunque luego no sirva para nada, porque no tengas un código que la utilice, puedes llegar a conseguirlo. Dividiendo la información en informaciones más pequeñas.

Por ejemplo, Jugada 1. jugada 2, jugada 3... cada 1 en una línea. Nombre del archivo situación final de ttt.

Sin embargo, esa información sobre el ttt será total y absolutamente inútil para averiguar de qué color es la yema de un huevo, o la probabilidad de que un huevo tenga 2 yemas.

Además, no estás haciendo ningún programa que sepa jugar al ttt... solo estás registrando jugadas y resultados posibles. Que como el ttt es un juego muy simple puedes abarcarlas todas. Pero eso no es enseñar a jugar a un programa, solo es reproducir jugadas pre-hechas.

Mi juego del ttt no reproduce ninguna jugada pre-hecha. El juego calcula el mejor posible movimiento y lo juega. No consulta ninguna tabla de situaciones finales del ttt.

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

El XML es un lenguaje de etiqueta, parecido al HTML, y por medio de estas etiquetas se organiza la información. Si accedes a un código HTML y entiendes el orden que lleva (no lo que hace cada etiqueta, sino el orden en el que está organizada la información) entonces entenderás lo que es el XML y como utilizarlo. En realidad es algo muy sencillo.

Es más, si buscas seguro que en google encuentras algún ejemplo sencillo y fácil de entender de como se organiza la información en un archivo XML.

[agleiva]

Iniciado por Kritik

Tienes un problema con la abstracción de tu programa. No estás abstrayendo de forma correcta el problema.

Este, mis queridos amigos, es el meollo de la cuestión. Siempre lo ha sido.

Ya te lo dije antes, @Tachikomaia, por más que no te guste que te lo digan. Necesitás ampliar tu marco de referencia. El nivel de abstracción que manejás es demasiado limitado y no te permite elaborar soluciones adecuadas para los problemas que estás planteando.

El Software no se trata de variables sueltas, escribir en archivos de texto y poner una cantidad infinita de if para ver todas las opciones posibles o cosas por el estilo. Se trata de aplicar las abstracciones adecuadas a cada problema, que te permitan escribir el código como un conjunto de reglas de interacción entre esas abstracciones.

Para darte un ejemplo, esto es lo que haría yo para el problema del ta-te-ti:

Código F#:

type Jugador = { Nombre: String}
 
type Posicion = { Fila: int; Columna: int }
 
type Valor = 
     | Vacío
     | Marcado of Jugador
 
type Casillero = { Posicion: Posicion; Valor: Valor }
 
type Jugada = { Jugador: Jugador; Casillero: Casillero }
 
type Juego = { 
    Jugador1: Jugador;
    Jugador2: Jugador;
    Casilleros: Casillero list;
    Jugadas: Jugada list }
 

Teniendo estas abstracciones, podés empezar a definir el juego como una interacción entre ellas, y el código mismo te va ayudando a programar correctamente porque ya tenés el modelo bien definido. A esto me refiero exactamente cuando te digo que para programar algo necesitás armar estructuras adecuadas, y no usar un montón de variables sueltas.

Para ampliar tu marco de referencia, la única forma que conozco el LEER. Leer sobre OOP, Programacion funcional, paradigmas de diseño, arquitectura, etc. etc. etc. Eso, y ver cómo resuelven este tipo de cuestiones otros programadores.

[Kritik]

Has registrado para un resultado final de ttt todos los pasos, todas las jugadas que hizo cada jugador, y en el orden en el que se hicieron.

Es decir, los pasos que se dan para llegar a una situación final.

También hay una serie de pasos a seguir para ir desde Madrid a París en bicicleta. Pero ese archivo del ttt no me sirve. Necesito un archivo que me indique específicamente mi problemática: Ir de Madrid a París en bicicleta.

A lo que voy es: Si de todas formas necesitas un código que utilice la información del ttt para jugar al ttt a partir de una situación inicial... por qué no hacer un programa que en vez de usar pasos pre-establecidos no aprenda a jugar al ttt?

Porque el código que utilices para el ttt no será ni remotamente parecido al que se utilizará para ir de Madrid a Párís en bicicleta. Y eso que ambos problemas tienen un cierto parecido en la mecánica de resolución.

Como comentario final, estás aún demasiado verde para enfrentarte al tipo de problemática que planteas. El tener un código que sirva para resolver cualquier tipo de problema.

Mi consejo es que practiques con problemas más sencillos. Problemas logísticos. En la sección Java hace poco me enfrenté a una duda muy chula, sobre misiles vs proyectiles. Pues enfrentándote a este tipo de problemas, y con la práctica en ellos... lograrás la habilidad para enfrentarte a retos lógicos mayores, como el que planteas.

[Tachikomaia]

Iniciado por Kritik

por qué no hacer un programa que en vez de usar pasos pre-establecidos no aprenda a jugar al ttt?

Cuando empecé mi intención era saber qué hacer en situaciones que para mí eran muy problemáticas, que tenía miedo de si hacer esto o lo otro, miedo de dejar de sentir las cosas que sentía, miedo de que en el futuro me arrepintiera. No era para que un programa use esa info para hacer cosas, era para usarla yo, abrirla leerla y usarla una vez que el programa la obtuviera.
Ahora también es eso.

Porque el código que utilices para el ttt no será ni remotamente parecido al que se utilizará para ir de Madrid a Párís en bicicleta. Y eso que ambos problemas tienen un cierto parecido en la mecánica de resolución.

En mi método lo que cambiaría son la cantidad de variables, los tipos, las condiciones a evaluar, etc. Pero la estructura sería la misma, es decir, el usar una acción, chequear si cumple el objetivo, en caso de que no entonces resetear, probar otra acción, etc, eso se mantiene.

Mi consejo es que practiques con problemas más sencillos.

El último que hice fue pasar de "A" a "AAAA". 1 variable, 1 cambio determinado por la acción -es decir no hay cambios involuntarios-... Es muy sencillo xD

En verdad les agradecería que se centren en la pregunta que hago... Es decir, me están hablando de métodos alternativos, sinceramente no sé si me ayuda o no, pero no es lo que estoy pidiendo.

[agleiva]

Iniciado por Tachikomaia

En verdad les agradecería que se centren en la pregunta que hago... Es decir, me están hablando de métodos alternativos, sinceramente no sé si me ayuda o no, pero no es lo que estoy pidiendo.

La solución que te acabo de mostrar resuelve exactamente el problema que estás planteando:

Iniciado por Tachikomaia

¿Describir situaciones y el cómo se llega a ellas?

El tipo/clase/estructura de datos Juego (en el ejemplo de arriba) DESCRIBE la situación actual del juego de tatetí mediante la propiedad Casilleros. Es decir, esa propiedad contiene el estado actual del tablero, ya que es una lista del tipo Casillero en la que cada casillero tiene una posición y un valor, que puede ser Vacío, o Marcado, y si es Marcado tendrá la referencia al jugador que lo marcó.

Luego, para saber cómo se llegó a esa situación, no se necesita como vos planteás una copia exacta de la situación inmediatamente anterior, si no que lo que se necesita es la lista de pasos que se dieron desde el principio de la partida hasta llegar a la situación actual, y esa lista de pasos está contentida en la propiedad Jugadas, que es una lista del tipo Jugada en la que cada jugada hace refencia a un casillero, y al jugador que realizó la jugada.

Con esta lista se puede reconstruir todo el juego desde el principio, sin necesidad de persistir (guardar) ninguno de los puntos intermedios, a menos que se desee claro.

Luego, teniendo una estructura de datos adecuada, se puede serializar/deserializar (en algún formato que quieras por ejemplo XML o JSON) la misma desde un archivo (por ejemplo) para guardar/leer fácilmente, sin necesidad de realizar la escritura del archivo campo por campo (o por "variable" si querés).

Finalmente, si te interesa hacer algo como esto de manera genérica (quitando el ejemplo específico del ta-te-ti, pero teniendo una estructura que te permita guardar pasos, estado y actual y condiciones, te puedo mostrar como haría usando Generics.

[Tachikomaia]

Lo plantearé de otro modo.



He representado a una persona en un pequeño laberinto y la salida. Las zonas negras representan paredes y a esos casilleros la persona no puede llegar. Las acciones posibles son 4: Moverse 1 casillero hacia...
1- arriba.
2- abajo.
3- la derecha.
4- la izquierda.

¿Qué pseudocódigo usarían para un programa que busque el camino más corto? Quiero ver si en este caso tienen que hacer las descripciones con las características que dije en el 1er post o no.

Ah, y debe guardar los datos de alguna manera, de modo que si usara esos datos sabría ya a donde ir. No pido el pseudocódigo para que use esos datos, simplemente para que se generen.

Gracias.

[Tachikomaia]

No sé realmente si estoy pidiendo algo diferente, pero yo diría que no, simplemente cambié el ejemplo a ver si así nos entendemos mejor. Diría que en esencia es lo mismo porque es la búsqueda de la mínima cantidad de acciones para llegar a una situación. Es casi lo mismo que mínima cantidad de movimiento para llegar a un sitio.

[Tachikomaia]

Yo no entiendo lo que dice aquí:
https://es.wikipedia.org/wiki/Algori...stra#Algoritmo
Daré mi respuesta.
1- Describir la situación origen (SO).
2- Describir la situación actual (SA, por ahora es igual que SO).
3- Act=1
4- Usando la acción nro(Act), modificar SA.
5- Chequear si cumple el objetivo.
6A- Si lo cumple ver cuántas acciones se realizaron.
6AA- Si es una, decirla y fin.
6AB- Sino, decir la última, y ver cual fue la situación anterior, decir qué acción se realizó en ella, y así sucesivamente hasta que la situación en cuestión sea la origen. Fin.
6B- Sino, ver si SA está en la "base de datos" o no.
6BA- Si no está, agregarla (y cual era la situación anterior (SO) y qué (Act) se hizo en ella), y también agregarla en otra BD, que es sobre situaciones no resueltas (en este caso no se requiere saber cual era la anterior ni qué se hizo).
7- Act++
8A- Si Act<5, SA=SO e ir al punto 4.
8B- Sino, Act=1
9- SO=una de las situaciones sin resolver (uso un contador para determinar cual).

Más o menos es eso.

[agleiva]

Iniciado por Tachikomaia

Yo no entiendo lo que dice aquí:
https://es.wikipedia.org/wiki/Algori...stra#Algoritmo
Daré mi respuesta.
1- Describir la situación origen (SO).
2- Describir la situación actual (SA, por ahora es igual que SO).
3- Act=1
4- Usando la acción nro(Act), modificar SA.
5- Chequear si cumple el objetivo.
6A- Si lo cumple ver cuántas acciones se realizaron.
6AA- Si es una, decirla y fin.
6AB- Sino, decir la última, y ver cual fue la situación anterior, decir qué acción se realizó en ella, y así sucesivamente hasta que la situación en cuestión sea la origen. Fin.
6B- Sino, ver si SA está en la "base de datos" o no.
6BA- Si no está, agregarla (y cual era la situación anterior (SO) y qué (Act) se hizo en ella), y también agregarla en otra BD, que es sobre situaciones no resueltas (en este caso no se requiere saber cual era la anterior ni qué se hizo).
7- Act++
8A- Si Act<5, SA=SO e ir al punto 4.
8B- Sino, Act=1
9- SO=una de las situaciones sin resolver (uso un contador para determinar cual).

Más o menos es eso.

Emm.... Esto no tiene absolutamente nada que ver con lo que planteaste primero.

Tu pregunta fue

Iniciado por Tachikomaia

¿Describir situaciones y el cómo se llega a ellas?

Y ahora estás preguntando por un algoritmo de PathFinding.

Googleando "PathFinding [XXX]" donde [XXX] es el lenguaje de programación que quieras usar encontrás muchas respuestas a ésto.

Por cierto, el algoritmo de Dijkstra requiere que se sepa de antemano las distancias entre cada uno de los puntos posibles. Creo que no es aplicable a tu caso.

Y si, yo empezaría por crear las estructuras de datos adecuadas, sobre todo si la intención es posteriormente persistirlas a disco.

Los pasos que planteaste no resuelven tu problema, o al menos no de la forma que lo estás planteando, porque requieren que se ingresen manualmente las acciones a realizar, en lugar de que la máquina las encuentre por sí misma.

[Kritik]

Pongamos que el muñeco planteado en el problema 2 está en la casilla de salida, porque ya ha llegado hasta la salida.

En ese caso, puede haber llegado ahí tras múltiples combinaciones. Puede haber pasado por casillas 2 veces tras tomar un camino equivocado, con las múltiples combinaciones que esto significa.

Por ejemplo, el algoritmo de fuerza bruta para salir de un laberinto sea cual sea (y si alguna vez te ves en uno puedes utilizarlo y llegarás a salir de él) es poner la mano en una pared de dicho laberinto, y empezar a andar sin separar la mano y sin cambiar de dirección. Tarde o temprano saldrás del laberinto.

Sin embargo también puedes haber llegado directamente a la salida, pasando por el menor número posible de cuadros hasta llegar a la salida.

Sea cual sea el algoritmo que hayas usado has llegado a una solución satisfactoria. ¿Nunca has tomado un camino con el coche para ir a algún sitio, sabiendo que había otro más corto pero desconocido... y para no perderte has tomado el camino que si conoces? Yo si.

Lo que tú pides es simplemente un historial de situaciones total y absolutamente distintas de resolución de problemas.

Problema: Tengo hambre.
Pasos a seguir:
Paso 1: Llegar a la cocina.
Paso 2: Abrir nevera.
Paso 3: Escoger alimento.
Paso 4: Preparar alimento para ser ingerido.
Paso 5: Ingerir alimento.

Como ha llegado la tostada de mermelada a mi mano... estando yo en un principio en mi habitación? Muy fácil... he seguido los pasos.

La solución a tu problema es fácil:

1.- Crea tus propios históricos... es decir, cuando te has encontrado un problema y lo has resuelto, lo escribes para futuras consultas.

2.- Utiliza los históricos de otros... es decir, cuando te has encontrado un problema has consultado como han resuelto otros dicho problema, y qué pasos han seguido. Si los históricos están bien documentados especificarán la situación inicial y la situación final.

Ejemplo de histórico ajeno:

En estos pasos pasamos de estar hambrientos estando en la calle, lejos de casa... a estar saciados y viendo la televisión en nuestro sillón de nuestra casa:

Paso 1.- Averiguar la parada de autobús más cercana.
Paso 2.- Llegar a la parada del autobús.
Paso 3.- Esperar al autobús.
Paso 4.- (...)

Si tú te encuentras alguna vez en la situación inicial de ese histórico ajeno y quieres llegar a la situación final de ese mismo histórico... solo tienes que seguir los pasos y llegarás. Ya no tienes ni que pensar como resolver el problema, solo tienes que seguir paso a paso las instrucciones.

Eso significa que puede que no sea la forma más óptima de hacerlo, pero si es un buen histórico llegarás a la situación final que querías.

Lo bueno de compartir históricos de resolución de problemas es que puede haber otras personas que descubrieron una solución más eficiente desde la misma situación inicial. Al igual que el que puso la mano en una pared del laberinto anduvo mucho más que el que recorrió menos cuadros, empezando los 2 desde la misma situación. Y compartiendo resoluciones a distintos problemas podremos deducir que unas maneras de resolver problemas son mejores que otras. Y así podremos escoger un histórico frente a otro, aunque ambos expliquen la misma situación final partiendo desde la misma situación inicial.

Y eso es lo único que puedes hacer para resolver el problema que aquí planteas: Tener históricos distintos para cada uno de los problemas con los que te encuentres. Además, para cada uno de los problemas puedes tener más de un histórico. Eso ya elijes tú como te organizas.

Por otra parte, el formato en el que debes de guardar dichos históricos debe de ser en lenguaje natural. Es decir... la lengua que uno conozca (español, inglés, francés, etc) porque si existiese algún método de comunicación que llegase a ser tan exacto como un lenguaje, con todos sus matices para cada uno de los detalles que pueda tener un problema... ¿qué necesidad habría del lenguaje?

Si para la resolución de cualquier problema se pudiese hacer con un código O_z_X_X... (etc) y con un código así se pudiese salir del laberinto, o calcular la hora de llegada de un tren... ¿Qué necesidad habría del lenguaje? Se utilizaría ese código que sería más sencillo, y por tanto más eficaz para transmitir información.

Y por qué? Porque tú mismo has comentado en otros posts que, utilizando nombres incongruentes con el concepto al que hacen referencia al pasar el tiempo te olvidas de lo que significan.

¿De qué te sirve entonces un archivo con nombre O_z_X_X, etc... si a los 6 meses de usarlo ya no sabes para qué sirve por inventarte tú mismo su nombre? Y si ese archivo está el nº 1436 de una lista de 5693 elementos? Como para acordarte de qué significa cada 1. Y después de 6 meses sin encontrarte con este problema te encuentras con el mismo problema y, por no saber reconocer el histórico tienes que preocuparte de nuevo de como resolver el problema, o de encontrar un nuevo histórico diferente (propio o ajeno) porque el que tienes no sabes encontrarlo. Y por eso necesitas el lenguaje natural. Para que si tienes un archivo llamado "GanarJuegoTTT" tengas una ligera idea de lo que contiene dicho archivo.

[Malenko]

Iniciado por Kritik

Por ejemplo, el algoritmo de fuerza bruta para salir de un laberinto sea cual sea (y si alguna vez te ves en uno puedes utilizarlo y llegarás a salir de él) es poner la mano en una pared de dicho laberinto, y empezar a andar sin separar la mano y sin cambiar de dirección. Tarde o temprano saldrás del laberinto.

El algoritmo que tu dices para salir del laberinto no funciona siempre. Hay laberintos que tienen bucles, de forma que si usas el truco de ir siempre por la misma pared (derecha o izquierda) te quedas atrapado. Además, para salir de un laberinto ya existe un algoritmo.

[Kritik]

Iniciado por Malenko

El algoritmo que tu dices para salir del laberinto no funciona siempre. Hay laberintos que tienen bucles, de forma que si usas el truco de ir siempre por la misma pared (derecha o izquierda) te quedas atrapado. Además, para salir de un laberinto ya existe un algoritmo.

Se me ocurren situaciones en un laberinto, con bucles, en los que sea imposible dislumbrar pasillos por los que no se haya pasado. Si, quizá la primera vez que se pasa se ve un cruce, y se elije uno de los 2 caminos. Pero es posible que no se vuelva a encontrar ese mismo cruce si se evita pasar por zonas ya señalizadas. Porque... cuando casi todo el laberinto se ha señalizado... ¿como se distingue por donde se ha pasado de donde no? Y si la única manera de llegar a un pasillo no señalizado es recorrer mucho tramo si señalizado? Como se sabe que para encontrar ese pasillo no señalizado se ha de andar por uno, o por otro pasillo si señalizado?
Ya te aseguro yo que si me veo encerrado en un laberinto intentaré, en primer lugar, hacer trampa para salir de él. Por ejemplo... siendo un laberinto de plantas... romperlas atravesando los muros de plantas en línea recta.

Vamos, que yo no me muero por perderme y no salir de este laberinto:

[Tachikomaia]

Iniciado por Kritik

Por ejemplo, el algoritmo de fuerza bruta para salir de un laberinto sea cual sea (y si alguna vez te ves en uno puedes utilizarlo y llegarás a salir de él) es poner la mano en una pared de dicho laberinto, y empezar a andar sin separar la mano y sin cambiar de dirección. Tarde o temprano saldrás del laberinto.

Creo que eso sería una fuerza bruta lógica, y que no te serviría si estás en un borde y la salida más bien en el centro, en cuyo caso quizá tampoco sería lógica xD

Lo que tú pides es simplemente un historial de situaciones total y absolutamente distintas de resolución de problemas.

No sé si te entiendo. Yo en el caso del laberinto lo que pedí es un algoritmo que busque la mínima cantidad de acciones dentro de las posibles (ya las mencioné) para hallar la salida, y que al terminar las muestre en pantalla, o sea: 1, 1, 4.
Y especialmente, preguntaba si lo pueden hacer sin describir situaciones y el cómo se llega a ellas. Y si lo hacen sin eso, pregunto cómo, y sino, cómo las describen si no pudieran usar archivos externos.

La solución a tu problema es fácil:

1.- Crea tus propios históricos... es decir, cuando te has encontrado un problema y lo has resuelto, lo escribes para futuras consultas.

2.- Utiliza los históricos de otros... es decir, cuando te has encontrado un problema has consultado como han resuelto otros dicho problema, y qué pasos han seguido. Si los históricos están bien documentados especificarán la situación inicial y la situación final.

Yo no pretendo generar una "lista" (por no decir bd) de los problemas enfrentados y cómo se resolvieron, simplemente 1 vez para cada problema (y subproblemas que tenga ese, pero en fin, es 1 vez), y sólo porque fue la forma que me pareció mejor, por eso estoy preguntando si hay otra. Eso de la lista sería bueno, pero por ahora no es lo que intento. Ya hice las preguntas más arriba...

Y eso es lo único que puedes hacer para resolver el problema que aquí planteas: Tener históricos distintos para cada uno de los problemas con los que te encuentres.

Ajá, entonces -a riesgo de no estar haciendo la pregunta correcta, sin embargo- ¿cómo serían esos históricos? Hablame de algo de informática, sencillo, como el tateti o algo así. Algo que una computadora pudiera entender sin tener que decirle tanto sobre cómo. Que no es lo mismo decir Inicial.txt:
V1=Vacío
V2=Vacío
V3=Vacío
V4=O
V5=X
V6=Vacío
V7=Vacío
V8=Vacío
V9=Vacío
que decir:
Inicial.txt:
Estás lejos de tu casa.

Pero, he dicho que con mi forma de hacer las cosas requiero que el nombre del archivo diga la situación actual y su contenido sea la anterior y qué se hizo en ella. El caso que puse como inicial fue sólo para darte un ejemplo, pero paradójicamente también cumple eso -para evitar que se repita un if al final, manías que no explicaré, lo siento-.

Por otra parte, el formato en el que debes de guardar dichos históricos debe de ser en lenguaje natural.

Pues sería "El casillero superior izquierdo está vacío, y también el superior central, el superior derecho... etc.txt". Sería complicado hacer que el programa -que usa números- transforme el contenido de las variables -que marcan el contenido de los casilleros- en lenguaje natural, y la memoria requerida sería mayor (los archivos tendrían nombres más largos lo cual también da problemas). Para el tema que dices de las "listas" sí sería importante algo que se entienda, pero lo que yo digo se usaría 1 vez y se sabe qué significa cada cosa, porque es un problema que se acaba de plantear. En todo caso se puede poner al final, por ejemplo (para el laberinto):
1 (esto significa moverse hacia arriba)
1 (arriba)
4 (izquierda)
...especialmente en casos en que hay muchas opciones (como en Final Fantasy 5 tendría un Mimic con X Magic, Summon y Combine).
De hecho puede ser:
arriba
arriba
izquierda
Tienes razón, pero es sólo un detalle, en principio lo importante es solucionar problemas...

Si para la resolución de cualquier problema se pudiese hacer con un código O_z_X_X... (etc) y con un código así se pudiese salir del laberinto, o calcular la hora de llegada de un tren... ¿Qué necesidad habría del lenguaje? Se utilizaría ese código que sería más sencillo, y por tanto más eficaz para transmitir información.

Usaré códigos como ese, si no veo algo mejor.

Y por qué? Porque tú mismo has comentado en otros posts que, utilizando nombres incongruentes con el concepto al que hacen referencia al pasar el tiempo te olvidas de lo que significan.

Como he dicho, en este caso no importa porque sólo se usa 1 vez, en el momento. Es como una calculadora, pones 2+2 y te dice el resultado, y tú al año no recuerdas si estabas sumando manzanas o qué.

[Kritik]

No se qué quieres conseguir. No se si tú te explicas mal o que yo no lo entiendo. Siento no poder ayudarte.

En cualquier caso lo que si que se nota es que tu falta de unos fundamentos de programación bien asentados transcienden del hecho de tener un cacao descomunal con las variables y su forma de usarse hasta el planteamiento completo de los problemas. Abstrayéndolos de una manera total y absolutamente ilógica.

[Malenko]

Cuando una persona en lugar de usar un array de 9 posiciones para jugar al tateti/tictactoe/3-en-raya usa 9 variables diferentes....es que efectivamente hay un problema gordo de base.

[agleiva]

Iniciado por Malenko

Cuando una persona en lugar de usar un array de 9 posiciones para jugar al tateti/tictactoe/3-en-raya usa 9 variables diferentes....es que efectivamente hay un problema gordo de base.

Podemos llevar esta afirmación un poco más lejos. Los lenguajes OOP nos enseñan que es válido tener estados de los datos que representan situaciones que en la realidad son inválidas o imposibles:

Código C#:

var algunCasillero = new { Marcado = true, Jugador = null };
 

podríamos meter validaciones para que tire un Exception en runtime, pero el compilador no tiene noción de que este es un estado inválido: si el casillero está marcado, efectivamente tiene relacion con algún jugador, y null no es un valor válido.

En los lenguajes FP, uno puede usar una Discriminated Union para hacer que los estados inválidos sean imposibles de representar:

Código F#:

type Casillero =
       | Vacío
       | Marcado of Jugador
 
let algunCasillero = Vacío //Correcto
let otroCasillero = Marcado // Error de compilación
let tercerCasillero = Marcado(null) // Error de compilación
let cuartoCasillero = Marcado(jugador1) // Correcto
 

Nótese que de ésta afirmación uno puede inferir de inmediato lo siguiente: los lenguajes de programación no son meramente "herramientas". Un lenguaje condiciona la manera de pensar de uno. Cuanto más rico es el lenguaje (o más bien cuanto más rico es el Type System que usemos) mayor es la medida en la que podemos crear abstracciones correctas de los problemas y entidades de la realidad, y sus reglas de interacción. Y uno aprende a identificar casos de uso en el código para estas abstracciones: volviendo de F# a C# me encuentro con situaciones en las que usaría DUs, pero éstas no existen en C#...

[Malenko]

Por supuesto, lo ideal sería usar una solución basada en POO, pero quería plantearle una solución más "sencilla" con lo básico que te enseñan en cualquier curso de programación básico. Y no a usar un fichero donde definir 9 variables para cada posición.

[agleiva]

Iniciado por Malenko

Por supuesto, lo ideal sería usar una solución basada en POO

Ese es justamente mi punto @Malenko, desde el punto de vista de OOP, uno ve a la programación estructurada o procedimental como algo terriblemente rudimentario, y piensa que el nivel de abstracción que proveen éstos paradigmas es demasiado limitado para ciertos problemas.

Luego, desde el punto de vista de FP, uno piensa lo mismo de OOP... el nivel de abstracción que proveen los lenguajes OOP como C# o java es limitado comparado los lenguajes funcionales. Eso no quita obviamente que OOP sea totalmente dominante en el ámbito laboral, pero no es el punto.

[Tachikomaia]

Iniciado por Malenko

para salir de un laberinto ya existe un algoritmo.

Podrías poner una implementación de ese algoritmo? Ayer no se me ocurrió buscar con esa palabra (implementación) pero ahora googlé así y no aparece. Miré este video:
https://www.youtube.com/watch?v=g1hiCeANfDo
...que manda a una página pero está inactiva. De alguna forma el programa marca los sitios en que ya -supongo- probó todos los movimientos posibles. ¿Cómo hace eso? ¿cómo sabe que ya pasó por los sitios que ha pasado? Dudo que requiera memorizar el cómo llega a ellos, pero en fin, se parece a lo que pido.
Lamentablemente el libro que tenía de IA me lo afanaron por prestarlo, pero recuerdo algo sobre grafos, guardaban pares de variables o algo por el estilo ¿quizá 2 arrays? Ahora bien, imaginate que el laberinto fuese variable, es decir, que no fuese sólo un tema de grafos y de dónde está el personaje, sino con otras variables como cantidad de hechizos disponibles de romper 2 paredes en tu dirección, de romper las que estén a tu alrededor, de atravesar una, de ver detrás de 2 en tu dirección, etc, puertas que se abren o cierran según la cantidad de turnos (por ejemplo en los pares), etc. Dudo que alcance con guardar pares de variables. Igual me serviría ver una implementación del algoritmo, para empezar.

Acá quizá hay:
http://shammael.crisopeya.eu/es/2007...intos-en-java/
pero claro lo que viché no lo entendí y es bastante largo.

[Kritik]

Iniciado por agleiva

Luego, desde el punto de vista de FP, uno piensa lo mismo de OOP... el nivel de abstracción que proveen los lenguajes OOP como C# o java es limitado comparado los lenguajes funcionales. Eso no quita obviamente que OOP sea totalmente dominante en el ámbito laboral, pero no es el punto.

Cuando llega algo nuevo que es claramente superior a lo existente triunfa. Como en la naturaleza, cuando llega una especie que se adapta mejor que ninguna anterior al medio ambiente (incluyendo la existencia de otras especies) triunfa y se reproduce como la espuma. Cuando esto no pasa, la especie puede llegar a sobrevivir por un tiempo pero tarde o temprano encontrará una dificultad que la haga desaparecer.

Lo mismo pasa a todas las creaciones hechas por el hombre. O se adaptan mejor que ninguna otra a la función para lo que han sido creadas o pueden sobrevivir por un tiempo, pero al final desaparecerán. Igual que le pasó al DVD. El DVD era una clara ventaja sobre el VHS y en muy poco tiempo lo sustituyó. Sin embargo antes todos teníamos Messenger incluso en el móvil hasta la llegada de WhatsApp que se adaptó a la necesidad de envió de mensajes a móvil mejor que ningún otro. Y por eso es un producto que usa muchísima gente. Después han salido otros productos que, aunque son mejores, tienen la desventaja de que no cubren necesidades no cubiertas. Y por eso no triunfan.

Lo mismo le pasa al FP. Si la POO sigue siendo la más utilizada y no hay crecimiento en la FP es porque no se adapta al medio, y por tanto no es mejor forma de abstractar los problemas para llevarlos a un lenguaje. Si esa forma de afrontar los problemas hubiese sido mejor que la POO hubiese tenido un crecimiento frente a lo anterior igual que el que tuvo la POO cuando nació.

Y te voy a explicar por qué la FP no ha triunfado frente a la POO ni nunca lo hará.

Cuando una persona quiere hacer algo... quiere hacerlo por sí misma, y realizar una FUNCION por sí misma. Para realizar dicha función puede necesitar de OBJETOS, para usarlos como herramientas. Lo que no quiere es delegar esa función en algo/alguien porque explicar exactamente lo que quiere y como lo quiere es un esfuerzo mayor que realizarlo él mismo.

Cuando un comercial en una tienda vende una televisión, quiere contabilizar la venta. Y para ello quiere un objeto que le ayude a contabilizarlo. Y lo mismo le pasa a los programadores. Los programadores no quieren funciones, quieren objetos que les ayuden a hacer las funciones que ellos mismos quieren hacer. Y eso se da de manera natural en la forma en la que tenemos las personas de ver el mundo. Cualquier cosa que sea contraria a la manera en la que tenemos las personas de ver el mundo, y que no se adapte a esta manera... no va a triunfar nunca.

Otro ejemplo es el jefe de una tienda de informática que tiene a un técnico trabajando para él. Por mucho que se intente nombrar al técnico, englobándolo dentro de un concepto abstracto como es el de "Servicio técnico"... y por mucho que el jefe diga "Yo se lo doy al servicio técnico"... en el fondo sabemos que son personas, no son abstracciones. Y que lo que sea que quiera dárselo "al servicio técnico" se lo va a dar a una persona.

Resumiendo: Lo que las personas ven es que son los OBJETOS los que realizan funciones. No las funciones las que se sirven de objetos para ser realizadas.

PD: Perdón por desvirtuar. Aunque si nos ponemos a pensar... también al creador del hilo le vendrá bien esta respuesta.

[Profesor_Falken]

OOP vs FP

Madre mia, otro flamewar que se aproxima...

[Malenko]

Como la cosa siga saliéndose de la pregunta inicial planteada empezaré a sacar tarjetas... Si queréis discutir sobre programación funcional abrid un nuevo post y no ensuciéis este.