Mensajes

Los operadores no son variables.
...pero, en .NET puedes sobrecargar los operadores o definir los propios.

Podrías implementar un operador 'Operar(x,y,z)', donde uno de los parámetros fuera precisamente el operador a utilizar (basado en una enumeración), los otros parámetros serían los propios del operador.
en realidad equivaldría a una función donde pasas esos parámetros y allí mediante un 'select case' evalúa la expresión con el operador elegido.

La ventaja de definir e implementar un operador es que se puede usar de la manera concreta que precises.

... y me salta  el cartel en rojo  del smart, es normal esto?

el qué?...

Tánto te cuesta poner una captura o por lo menos hacer una descripción clara de tu problema????

... 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.

Pues tras la inversión de Elon Musk y la inmediata subida hasta por encima de los 40.000 tentado está uno... 

Ya leí más o menos esto:
https://es.wikipedia.org/wiki/%C3%81rbol_(inform%C3%A1tica)
Y en ningún momento dicen cómo se describe un árbol. Además dicen que ciertos casos no son árboles, pero creo que yo los precisaría.

Wikipedia es una 'enciclopedia universal', no exactamente una enciclopedia informática. Recoge muchos artículos del tema, pero ni wikipedia ni ninguna enciclopedia conocida está enfocada a describir el asunto paso a paso como si se fuera un principante absolutamente lego en toda materia.

Por naturaleza del propio asunto, suelen describirse en términos que ya deben dominarse, sino sería inabordable.
Si al explicarte una bicicleta, en vez de decir 'pedal', cada vez tuviera que dar la explicación exahustiva de lo que es un pedal, describir la bicicleta llevaría 5.000 páginas. Ahí ya, si uno no sabe lo que es un 'pedal' puede buscar en la propia enciclopedia qué es un pedal, pero incluso así, un artículo sobre 'pedal' no tiene porqué contener la 'historia del pedal', o puede que solo se dén dos o 3 entradas históricas, ni tampoco tiene porqué venir 'cómo fabricar un pedal' ni los 500 artículos relacionados al pedal que en algún momento a alguien le pudiera interesar, pués eso requeríría un libro específico dedicado al 'pedal'... una enciclopedia solo posicionaría el 'pedal' en un contexto explicando qué es, algo sobre su origen y sus usos. Incluiso desciribiendo el pedal también se asumirá que el lector sabe lo que es 'roscado' y 'tornillo', etc...

En fin, el 'lee...' lleva puntos suspensivos, para indicar que continues, leer solo 2 artículos puede resolver las dudas que puntualmente uno tenga, o puede necesitarse leer bastante más... todo depende del nivel que se tiene   y el nivel al que se quiere llegar, cuanto mayor la diferencia tanto más lectura será conveniente.

Acá
https://es.wikipedia.org/wiki/Teor%C3%ADa_de_grafos#Estructuras_matriciales
Dice algo...
V = { 1, 2, 3, 4, 5, 6 }
A = { {1,1}, {1,2}, {1,5},
{2,3}, {2,5}, {3,4},
{4,5}, {4,6} }
Pensaré qué puedo hacer con eso.

Sobre el modo de representación, puedes hacer una abstracción y por ejemplo no necesitas para nada mantener las ridículas llaves '{} , puedes perfectamente sustituir los separadores de contenidos por otros símbolos (por ejemplo las llaves por paréntesis, que al menos en español resultan más cómodos (de teclear al menos)) a tu elección o incluso eliminarlos (como se hará a continuación y conservando aún enteramente su significado).
por ejemplo podrías hacer:
V = ABCDEF
X = AA, AB, AE, BC, BE, CD, DE, DF

Donde claramente se observa que las letras A-F remplazan la identificación de los nodos etiqeutados en la imagen con valores 1-6 y donde no resulta preciso usar las llaves, la concatenacón es suficiente para indicar una separación de elementos individuales y la coma en grupos... es más claro, simple, legible y procesable. Si los nodos además de expresar una identificación del mismo han de expresas un valor, si será preciso otro separador para diferenciar el identificador de su valor...
Nota que 'V = ABCDEF' simplemente describe que 'A-F' son nodos de un grafo llamado 'V', y que 'X = AA, AB, AE, BC, BE, CD, DE, DF' describe las relaciones entre los nodos, así el nodo 'A' (1 en la imagen) está conectado a los nodos 'A', 'B' y 'E' (1, 2 y 5 en la imagen)
También podría describirse del siguiente modo:
V = ABCDEF
A = ABE
B = ACE
C = BD
D = CEF
E = ABD
F = E

Es decir cada nodo apunta a los nodos a los que está conectado.
Mediante iteración (para recorrer los elementos de un nodo) y recursion (para recorrer los elementos de un nodo obtenido durante la iteración). Si metes cada elemento en un array podrás explorar muchas y diferentes soluciones.

Puedes considerar una expresión en la forma 'Y = CDEF' como un nodo 'Y', con 4 nodos hijos 'C','D','E' y 'F', que pueden ser explorados uno a uno en un bucle o ser accedidos de diferentes modos. Y se podrían expresar con valores, por ejemplo 'Y= C:3;D:8;E:0;F:5'.

Yo uso mucho esa disposición para ciertos problemas más o menos complejos... y como 'hablar es fácil', vaya un ejemplo como demostración...

Pongamos como ejemplo, encontrar la solución en un laberinto (tomado de la red)... observa la imagen (que pongo un poco más abajo) se compone de 10x10 cuadrículas, que he etiquetado (para una fácil y clara comprensión) en horizontales 0-9 y en verticales A-J, se marca exactamente como nodo aquella casilla que supone un cruce, un cambio de dirección, que como se puede observar tienen 2, 3 o 4 direcciones (de 4 solo hay una, G6) y también los nodos que son finales (pués pueden ser marcados como punto final).
Carece de sentido práctico anotar como nodo A1, A2, A3, pués A1 lleva a A0 y a A2, pero no cambia de sentido, cualquier ruta que pase por A1, A2, A3... lleva hacia A9 (o hacia A9 si se recorre en sentido contrario), aunque podría ser el caso de que una casilla específica fuera 'la meta' en tal caso se añade, si no, al ser solo de paso, se resume en sus límites (las que llevan a través de ellas directamente sin posibilidad de cambio). La imagen vista, es más claro que detallada con palabras (como tantas veces).


El laberinto puede verse adjunto en la imagen recién adjuntada, y marcado todos los nodos que de él resultan, es un grafo... que yo traduzco como se ve a continuación y que es fácilmente deducible (aunque ya lo he explicado antes):
Vecindad de los nodos del grafo del 'laberinto.png'
------------------------
A0= A9|H0
A9= A0|C9
B1= B2|E1
B2= B1
B3= B5|C3
B5= B3
B6= B8|C6
B8= B6
C2= D2
C3= C4|B3
C4= C3|C6|D4
C6= C4|C9|B6
C9= C6|A9|J9
D2= D3|C2
D3= D2|F3
D4= D5|C4
D5= D4|E5
D6= D7|E6
D7= D6|E7
D8= E8
E1= E2|B1
E2= E1|G2
E4= E5|F4
E5= E4|E6|D5
E6= E5|D6|G6
E7= E8|D7
E8= E7|D8
F1= G1
F3= F4|D3
F4= F3|F5|E4
F5= F4
F7= F8|G7
F8= F7|I8
G1= G2|F1
G2= G3|G1|E2
G3= G2|H3
G4= G6|I4
G6= G7|G4|E6|H6
G7= G6|F7
H0= H3|A0|J0
H3= H0|G3|I3
H5= H6|I5
H6= H7|H5|G6
H7= H6
I1= I3
I3= I4|I1|H3
I4= I3|G4
I5= H5
I6= I8
I8= I6|F8
J0= H0|J9
J9= J0|C9

El programa recibe dos llamadas.
En la primera introduce y prepara los datos, esto es esta lista se concatena mediante un separador, se envía junto a otros parámetro (por ejemplo, el separador de cada campo conceptualizado al caso).
En la segunda se explicita que se va a hacer, (el tipo de búsqueda), si se van a considerar pesos o no, y el criterio del peso o costo (por ejemplo encontrar las soluciones con el valor exacto, con el valor menor a uno dado, etc...) el nodo inicial y final. Si no se señala un nodo inicial, señala que cualquier lo puede ser. del mismo modo el nodo final puede ser un comodín indicando con ello, que cualquiera puede ser el nodo final, pero si se especifica uno, ese y solo ese será el final).

En este ejemplo solo se trata de buscar las soluciones entre un nodo 'X' y otro nodo 'Y' que uno especifique, el programa tendría que buscar las soluciones posibles... la búsqueda puede ser por fuerza bruta (no aconsejable cuando la explosión combinatoria es elevada), o acotada (por ejemplo si se establecen pesos y se busca un peso exacto, una vez superado dicho valor no es preciso seguir explorando soluciones desde el punto en que ya se ha sobrepasado dicho valor pués añadir nodos no haría si no aumentar dicho valor cuando ya sabemos desde cierto punto que ese camino ya no es válido, etc...

El ejemplo actual puede verse como el nodo inicial es A9 y el nodo final es D8, se buscan todas las soluciones posibles entre dichos nodos. Se localizan 4 y se lista la ruta de cada una...


En este ejemplo no se han especificado pesos, pueden establecerse, pués es fácil contar las casillas entre dos nodos, por ejemplo redefiniendo el nodo A0 con pesos sería: A0= A9:9|H0:7
De igual modo desde A9 a A0 habría un peso de 9 y desde H0 a A0 un peso de 7, en tal caso el peso o costo indicaría la distancia y en tal caso la búsqueda sería ligeramente distinta, pués al final devolvería (interesaría que fuera así), la de menor costo, es decir la solución que menos distancia arroje desde A9 hasta D8...
El grafo no está dirigido, esto es, se puede ir desde un nodo a cualquier otro y al revés no está restringido, cuyando un grafo está dirigido señala que solo s epuede recorrer desde un nodo a los adyacentes que estén dirigidos, por ejemplo,
imaginemos que una flcechita hubiera desde A0 a A9, A0 tendría la siguiente especificación: A0= A9|H0 , peor para A9, si no hubiera una flecha apuntando hacia A0, su especificación sería: A9= C9 en vez de A9= A0|C9


Esto es solo un ejemplo, la variedad de usos es enorme... muchos problemas que a veces uno les busca solución de cierta manera pueden igualmente ser resueltos con grafos, de hecho los lenguajes funcionales tiran mucho de esto.

Pero eso exige pensar y posiblemente cometer algunos prejuicios.

Guau. Si pensar es para ti un esfuerzo, entonces tu relación con la informástica se remite a que te quedes solo como un 'usuario', no un 'desarrollador'... Lo primero solo exige utilizar (mejor o peor), lo segundo exige sí o sí, pensar.

Suena como a alguien que dice que quiere ser submarinista, pero que le da miedo cualquier masa de agua mayor que la que cabe en el lavabo de su baño.

Con 'prejuicios' no tengo claro a que te refieres resulta ambiguo.

Si pensar es para ti un problema, no podrás hacer otra cosa que 'copiar y pegar' y me temo que en ninguna parte vas a encontrar lo que exactamente tu requieras justo para copiar y pegar. Considero que te pienses seriamente qué quieres conseguir y qué estas dispuesto a hacer, si lo uno no encaja con lo otro, estás perdiendo el tiempo y me parece que sería mejor que te dedicaras a otra cosa donde esos dos puntos estén en equilibrio (igualados).

No sé cómo funciona una calculadora, pero no creo que los resultados que arroja sean producto de haber probado candidatos como hace una fuerza bruta (que por cierto, creo que es lo que hago).

La fuerza bruta es la torpeza en forma presente.
Con alguna frecuencia me tengo que enfrentar a problemas cuya solución no es conocida, en esos caso la fuerza bruta es la última opción, cualquier heurística será siempre mucho mejor.

Estoy por leer algo cuando esté más despierto.

Descansa, si lo necesitas, pero lee... es todo un mundo maravilloso al que (al menos todos los interesados en el conocimiento), lejos de temer debieran tener por su 'amigo íntimo'.

Implicaría que muchos problemas tendrían una solución asequible en el tiempo.

Actualmente la única forma de saber si un número es primo, son 2. O bien buscar si ya existe en una lista que ha sido calculada, o bien calcularlo en ese preciso momento.

Implica que de existir una serie, conociendo su razón, podría resolverse con algo como x = Primo(k) de una forma más o menos inmediata, o en algo mayor de tiempo en la forma en que por ejemplo se resuelve la sucesión de Fibonacci. ...la actual como he dicho es tirar de una lista ya precalculada o recalcular.

Es decir si alguien pregunta cual es el primo que en la serie de primos ocupa el orden 25 millones? no se puede arrojar una respuesta inmediata, la idea es que en teoría exige calcular previamente los 25 millones para poder dar respuesta satisfactoria (salvo una lista ya calculada y memorizada con anterioridad).

Mira, por ejemplo en esta página tratan de utilizar voluntaros para calcular números grandes de los primos de Mersenne:
https://www.mersenne.org/primenet/

Encontrar una sucesión... exponiendo un ejemplo directo como caso:
Digamos que muchos algoritmos criptográficos que basan su fuerza en precisamente la laboriosidad de encontrar números primos, quedaría roto por completo...
Seguro que habría muchas prisas para remplazar tales algoritmos, pero abordar cambios podría llevar entre semanas y meses y al tiempo no podrían suspenderse determinadas actividades que depende de la seguridad que ofrecen tales algoritmos, probablemente habría muchos intentos de fraude (con visos de logro en alto porcentaje de casos cuando no dependan o estén reforzados de otros medios alternativos)...
Seguramente habría graves caídas en la Bolsa, nos acabaría afectando a todos, porque al final el mundo actual es un enorme tablero con piezas de dominó, que cuando cae una, caen casi todas. Vamos un caos en ese terreno, daría para una película...

Encontrar una solución es aprender algo.

De modo filosófico para una persona sí...
Si lo hace un programa, que encuentre una solución no aprende nada con ello. Toma una calculadora y multiplica 2 números, dime que ha aprendido aunque arroje la solución correcta. De la IA se espera que 'aprenda'...

Es importante no confundir las materias en objeto.

Bueno, sigo sin saber cómo nombrar o hacer un árbol. Y usarlo.

El foro no está concebido para ser una escuela e impartir lecciones, solo apoyos, apuntes, ayuda puntual... el trabajo de aprender recáe en cada persona individualmente.
Si tu ya conocieras los árboles, que tuvieras una duda concreta y puntual, pués vale preguntar y tendrías respuesta, pero no cabe enseñar a nadie desde 0, y mucho menos desde el nivel en que un 'aspirante' esté anclado en conocimientos (habitualmente poder adquirir ciertos conocimientos, supone conocer los que están por debajo de esa capa y que son necesarios para explicar y comprender lo que se cuenta)...

Hay chorrocientos libros para aprender, casi seguro que también haya muchas páginas donde se aborde el tema con mayor o menos proofundidad (incluso probablemente vídeos por youtube), pero vamos un foro no. Un solo hilo donde dijera: "enseño árboles", acabaría teniendo miles d epáginas, pués todo el mundo vendría a preguntar las mismas cosas respondidas mil veces, pero que en vez de buscar prefiere que se lo cuenten de nuevo otra vez bajo su perspectiva particular.

Mi consejo es que te compres un buen libro, si el dinero (como tantas veces) es un problema, seguro que todavía podrás descargarte alguno por la red... y si tampoco te vale por la razón que sea, Wikipedia, es una opción asequible a todo el mundo: Empieza por aquí... lee, lee y lee.
https://es.wikipedia.org/wiki/%C3%81rbol_(inform%C3%A1tica)

No. Los primos no siguen ninguna serie conocida. Aunque es un tema abierto, pués tampoco hay demostración en contra.

Lo que sí hay son series de primos que cumplen cierto patrón, por ejemplo los primos de Mersenne. Que son en la forma: p = (2^n)-1
Es decir es la serie de números (que son primos) que cumplen ese patrón.. entre medias hay más primos y hay números que cumplen ese patrón pero no son primos.

No sé si son este tipo de series lo que venías buscando.

No pillo que tiene que ver esto con lo que ponga en el currículum. No capto el contexto y lo he intentado 

Las empresas sabne de sobra que la mayor parte d ela gente infla su curriculum.
Un modo sencillo de saber la verdad, es preguntarles sin que ello les ponga en evidencia. Si pedirles la verdad ha de suponer pasar vergüenza, etc... insistirán en mentir.
"Tengo la confianza o la esperanza de conseguir los resultados deseados."
Si dominas un tema específico, por qué no vas a tener confianza en conseguir los resultados que esperas?. El único modo de que suceda eso (a priori),  es que en verdad no domines el tema.
Habrá otras razones, cuyas causas puntualmente, pero tú no tienes ningún modo de saber en este preciso instante, cuales podrían ser. La única a priori es que domines o no el tema para el que supuestamente se te contrate.

Feedback, como bien señala Machacador es retroalimentación en cualquier sentido. Se refiere por ejemplo a cosas de electrónica, en relaciones sociales, inclsuo en programación, desde el código, hasta el programa una vez completado... y como no, entre un autor y su público (por ejemplo músicos y fans).
Por ejemplo la frase "...el feedback entre el programador y sus usuarios...", refiere básicamente a las quejas o fallos del programa, que el programador tendrá en cuenta para corregir o mejorar la próxima versión.

Se cuela con excesiva facilidad demasiada teminología en el español sin necesidad (cuando tenemos palabras en nuestro idioma no es necesario importarlas, de hecho a veces creo que hasta convendría tomar medidas).

Según lo que dices con el ejemplo de la radio la traducción al castellano sería algo así como repetición, eco, retardo o repetición retardada.

Ahí el término correcto es 'acople'... Es como poner un espejo que se refleja en otro espejo, si la imagen tiene un pequeño ángulo se ven espejos infinitos, porque cada reflejo, refleja lo que el otro contiene y aquel contiene todo lo que este a su vez refleja.

'feed' es alimentar, alimentador, y 'back' retroceso, volver, de vuelta atrás...

Pero con lo del profesor y alumnos  sigo sin pillarlo, pero en términos de la afirmación del test "doy y solicito feed-back".

Un profesosr explica... y espera que los alumnos que no entiendan su explicación (aunque sea parcialmente), hagan las preguntas al respecto. Si el profesor responde una duda, puede de nuevo el alumno, volver a requerir otra aclaración de ahí lo de 'doy y solicito feedback.