... el ejemplo pero no sé usarlo bien ¿tengo que usar arrays? ¿y cómo sabe la máquina cuántas posibilidades hay estando en una casilla?
Si, utiliza básicamente arays uno actúa de stack.
Aunque se trate de grafos a menudo no es preciso ni construir una estructura de grafo ni de árbol. Son tan solo recorridos condionados según las peticiones. La función principal deriva a la otras según lo que s epida por optimización, pues no es óptimo comparar a cada instante que si se ha pedido tal o cual cosa entrar aquí o allí, se separan diferentes funciones muy similares donde cada una solo contempla en excclusiva lo que se requiere, y la comparación de lo que s epide se hace una sola vez, precisamente para derivar el trabajo a la fnción concreta.
¿y cómo sabe la máquina cuántas posibilidades hay estando en una casilla?
No sabe ni necesita saber nada.
Un nodo solo tiene acceso a los que se declara a su derecha, luego basta un bucle para recorrerlos. A su vez el ítem actual (obtenido en el ciclo actual) tiene otros declarados a su derecha, luego se invoca recursivamente, y donde aquí en el bucle hace ahora las veces de hijo, en esa llamada hace las veces de padre y se recorren sus nodos hijo. Tras cada 'hijo recorrido se tiene que verificar la condición requerida, si se cumple la solución pedida se informa, dispara un evento, etc... y se continúa con otros... salvo que la solicitud fuere 'salir tras encontrar la primera solución fuere cual fuere'. Cuando un bucle no tiene más ítems a su derecha que examinar pués sale, la función recursiva retorna a la que la llamó, y avanza al siguiente 'hermano'.
En realidad es muy similar a la jerarquía del sistema de ficheros... con la salvedad de que en una jerarquía de ficheros al ser arbórea, una carpeta jamás contiene a otra que a su vez contiene a esta. en un grafo la relación de 'hijo' puede ser bidireccional sin ningún problema, por eso no interesa el nombre de 'hijo' si no que se usa preferiblemente vecino, conexión.
Las posibilidades no necesitan ser precalculadas en el sentido de cúantas hay, el algoritmo subyacente hace el recorrido pertienente, simplemente te limitas a sumar uno a cada exploración iniciada cuando se explora. Fíjate que puede haber diferentes acotaciones, por ejemplo una que impide que un nodo se visite más de una vez (para eso se usa un 'stack'), por tanto si uno ya ha sido visitado no solo lo ignora si no que al ignorarlo, también se ignoran todos los vecinos y recorridos que continúan desde él... en el ejemplo si esto no se evitará hallaría soluciones circulares y entraría en un bucle infinito, porque cuantas vueltas se le permitiría dar?, 2, 5 40, 1 millón?. La respuesta es 1.
Yo quería hacer programas que resuelvan problemas que yo no sabía cómo.
mmm... tiene y no tiene sentido... a ver...
Se pueden hacer programas (que SI debes saber hacer), para que exploren soluciones complejas o que conlleven mucho tiempo.
El límite será siempre tu capacidad de realizar esos programas y por supuesto de esos 'problemas que no sabes'. Una cosa es no saber como lograr una solución concreta y otra muy distinta es saber que hay una solución y que se sabe como buscarla pero directamente no sabes como encontrarla.
Un ejemplo para que quede claro: el caso de los números primos... Supongamos que te piden el primo más pequeño que utiliza 60 cifras... directamente no podremos saber la solución (cual es el primo concretamente, ni tú, ni yo, ni nadie), pero al menos se necesita saber como buscar dicho primo, y en tal caso si se puede hacer ese programa que localice el primo deseado (tarde más o menos). Si en cambio no sabes como localizar un primo cualquiera (emplázalo fuera del ejemplo por otra cosa), entonces el fracaso al hacer el programa está asegurado. Carece de sentido intentar hacer algo que no se sabe. Es como si un indio de una de esas tribus que aún siguen perdidas en el Amazonas, quisiera hacer un submarino, cuando no conocen técnicas de fabricación, ni conocen los materiales precisos para aguantar la presión del agua, orientarse, respirar, moverse, etc...
La máquina además experimenta más rápido que yo y no se aburre, yo sí. Mi idea era pensar un poco para luego no tener que pensar tanto. El ajedrez sería un ejemplo. Hacer un programa que practique y luego yo lo imitaría.
Es el enfoque correcto para usar los ordenadores y la programación es el vehículo adecuado, pero te falta quizás el conocimiento y desde luego, deja ActionScript atrás... elige un lenguaje más universal.
Uno típico es suponer que entre más puntos de vida quite un ataque, mejor es la situación luego de usar ese ataque. En Pokemon Cards por ejemplo existe el movimiento Rage que entre más PV tenga perdidos más daño hace. Lo que significa que en ese caso puede que convenga quitar 2PV y luego 5, que quitar 5 y luego 2.
Vale, pero eso se llama suposición, no deja de ser un prejuicio, pero por prejuicio suele entenderse como desfavorable. La suposición en principio es buena pués te orienta un poco de por donde puedes ir, claro siempre dependerá de tu juicio... es adecuado siempre hacer una simple demostración que apunte a si puede demostrarse como falso o verdadero, si continuar con esa suposición llevará mucho tiempo y trabajo (para no perderlo tontamente, aunque a veces es necesario porque ciertas demostraciones no puedne ser satisfechas hasta que llegues a su última consecuencia).
De hehco fíjate si una suposición es buena que es bastante malo cuando no se te ocurre nada (cuando no tienes nada que suponer sobre el caso) y por tanto te encuentras vacío, sin idea, sin saber por donde tirar. La intuición, la suposición puede sacarte de ese vacío y suele valer el esfuerzo de analizarlo.
Insisto, lee... y remplaza ActionScript por otro lenguaje.
Autor
En línea
