¿Cómo detectar paréntesis redundantes? Avances.

[Tachikomaia]

Resumen en negrita.

Parece que expresiones como esta:
Variable1 < Variable2 y Variable1 < Variable3 o Variable2 == Variable3
son análogas a esta:
2 * 3 + 4
en el sentido de la prioridad: Así como los * se aplican antes que los +, las "y" se aplican antes que las "o".

Supongamos que tenemos:
A s B s C s D s E
donde las letras mayúsculas representan números y las s representan signos.


Los paréntesis son redundantes cuando no alteran el orden de las operaciones.


Redundantes tipo 1: Envuelven sólo un valor.
Ej: (A) s B s C s D s E

Quiero el pseudocódigo de un programa que genere expresiones que no tengan paréntesis redundantes. Generar las expresiones no es difícil (al menos las que intenté por ahora; hay otras), lo difícil para mí actualmente se relaciona con los paréntesis. Según pensé, luego de generar una expresión la podría variar poniéndole paréntesis.

Los que abren sólo se pueden poner en las posiciones indicadas por los números de arriba y los que cierran en los de abajo. Básicamente al inicio de una expresión no tiene sentido cerrarlo y al final no tiene sentido abrirlo. El programa siempre en algún punto cerraría los que abra así que no tiene que revisar si todos están abiertos y cerrados. Ej:
Posición de los abiertos: 1, 3
Cerrados: 2, 4
Resultado: (A s (B s C) s D) s E

Unos paréntesis son redundantes tipo 1 si un número está en ambos grupos
En criollo: Si se cierra a penas se abre.
Ej:
Posición de los abiertos: 1, 3
Cerrados: 3, 4
Resultado: (A s B s (C) s D) s E
¿De acuerdo? ¿se les ocurre un método mejor de nombrarlos/generarlos?


Redundantes tipo 2: Envuelven a todo el resto.
Ej: (A s B s C s D s E)

Ocurren cuando:
- En abiertos está el nro 1.
- En cerrados está el número más alto admisible.
y alguna otra condición que no llego a entender. ¿Cual/es?
El problema son casos como por ejemplo este:
(A s B s C) s (D s E)
Posición de los abiertos: 1, 4
Cerrados: 3, 5
Ahí hay 1 y 5 pero no hay falla, por eso falta alguna condición más.


Redundantes tipo 3: No envuelven algún + y no hay un * fuera.
Recuerden que eso del + y * es una analogía. Pero la cosa es que A * B * C = A * (B * C). En la práctica puede que no si el resultado de A * B o B * C es infinito en extensión, pero por ahora no trabajo con eso. Condición1 y Condición2 y Condición3 = C1 y (C2 y C3). Los paréntesis tienen sentido si implican alguna + y hay alguna * fuera. Es decir, cuando alteran el orden normal de las operaciones.

Por ahora no puedo decir cómo detectaría estos, si acaso puedo averiguarlo. Necesito hacer ciertos códigos o pseudos antes de poder analizar esto. Pero si alguno sabe detectarlos, agradezco la respuesta.


¿Hay algún otro tipo?

[Serapis]

Es cansino indicarte cosas que luego ignoras.

Y tampoco tiene sentido resolver un problema estricto, sin un contexto que le dé sentido... explica cual es el problema real, porque seguro que hay formas óptimas de resolverlo, que enfangarse en detalles nimios, sin importancia...

En resumen: ¿pará que se van a utilizar tales expresiones?, ¿cuál es la últilidad práctica que han de tener? y así se podrá ver una forma óptima y elegante de crearlas. Si tapas el monte y solo muestras una hoja, no te ayudas a tí mismo.

[Tachikomaia]

Es cansino indicarte cosas que luego ignoras.

Si es el caso te pido disculpas.

Y tampoco tiene sentido resolver un problema estricto, sin un contexto que le dé sentido...

Te lo explico entonces, aunque creo que ya te lo expliqué un poco en otro tema y no le veo mucho sentido a hacerlo.

Quiero hacer un programa que mejore el universo o descubra cómo. No simplemente mediante leer páginas como hace Google, sino razonando, inventando. Leer páginas de hecho no lo veo necesario en esto, no va por ahí.

Como no tengo idea de cómo hacer ese programa, lo que hice fue algo similar aunque muy sencillo, resuelve una duda muy sencilla. En el código pongo una respuesta base, escribo la condición que debe cumplirse para que la duda se considere resuelta, y digo que la respuesta se varíe de cierto modo hasta que cumpla la condición. Casi así:

Código [Seleccionar] Expandir

Candidato = 0;
Repetir
  Candidato++
Mientras Candidato < 10
Imprimir: "La respuesta es " + Candidato Eso según he visto es:
https://es.wikipedia.org/wiki/B%C3%BAsqueda_de_fuerza_bruta
De hecho la palabra "Candidato" la tomé de ahí.

No le digo al programa cual es la respuesta a la duda, aunque en este caso sea obvia y el programa no parezca tener utilidad. Lo que pasa es que es una práctica para acercarme a lograr mi objetivo... Como un principiante hace prácticas para aprender a programar algo que quiera.
Lo que hago es darle los medios para que averigüe la respuesta, como se enseña a pescar en vez de dar pescado, aunque en mi caso quisiera llegar a enseñarle a aprender lo que se necesite, no simplemente enseñarle a pescar.

Ahora tengo que complicar la duda para que parezca más la que realmente me interesa resolver. Para eso puedo:
A- Complicar la condición a cumplir.
B- Hacer que el programa averigüe también la respuesta base.
C- Hacer que el programa averigüe también cómo variar la respuesta base.
D- Hacer que el programa averigüe también cual es la condición a cumplir.
Etc, no viene al caso la lista entera.

Resulta que B, C y D, se podrían considerar otros programas con otras dudas, o sea, no hay por qué resolver 2 dudas en el mismo, estas son dudas más complicadas que llegaré a enfrentar luego de aplicar muchas veces A.
Lo que pasa es que hay dudas en las que desconocemos más que simplemente la respuesta, pero cuando eso pasa supongo que se puede plantear cada una por separado, en distintos programas. Por ejemplo puede que desconozcamos las posibles acciones que pueden realizarse (esto está relacionado con B y C). En el universo imaginate: ¿Cuales son las posibles cosas que pueden hacerse? Poner objeto A arriba de B, ETC, pero no sabemos todo.

Entonces, como di a entender, aplicaré A muchas veces, o sea voy a complicar la condición muchas veces. Voy también a ir agregando variables de la situación, o sea, en la duda inicial de ejemplo no hay variables de esas, pero las dudas normalmente incluyen alguna, por ejemplo la medida del lado de un cuadrado, posición de unas fichas, etc.

Por ende, me conviene hacer un programa que haga las complicaciones. Pero me refiero a que la condición sea más complicada, no es que la base deba ser igual. Por ejemplo si tenemos 10 == Candidato, la próxima podría ser:
Candidato < Variable1 y Variable1 < Variable2
De hecho Candidato podría no estar presente, aunque para eso debe modificar alguna variable. No viene al caso.

Es entonces un generador de expresiones condicionales. Se escribe la cantidad que se quiere generar, y el programa las genera.

Nota: De momento NO intento que las expresiones puedan tener modificaciones de las variables. Ej: V1*2 < V2+4

El problema es que esas expresiones deben cumplir ciertas condiciones... No deben tener contradicciones como:
Candidato < Variable1 y Variable1 < Candidato
O sea deben ser posibles de cumplir, pero también posibles de no cumplir, hay que evitar cosas como:
Candidato == Variable1 or Variable1 != Candidato
Y quisiera evitar redundancias como:
Candidato <= Variable1 or Candidato < Variable1
...pero estas cosas no es el tema al menos aún.

Resulta claro que quiero que las expresiones puedan tener paréntesis, pero sólo en tanto no sean redundantes. Porque me parece absurdo que los tengan si sobran, eso es todo.

El resto ya fue explicado más o menos...

Dada una expresión, se generaría un número al azar o dependiente de la cantidad de "os" que tenga, si tiene alguna "y" separando, no pensé en eso ^^u pero es que parece secundario: La cosa es que podrían agregarse paréntesis por ahí y por allá, como comenté en el 1er post, y entonces tendría que detectar cuales sobran y cuales no.

No son redundantes cuando cambian la "lógica" de la expresión.

Creo que eso es todo...

Puf.

Ah, por cierto: Si crees imposible hacer un programa que mejore al universo o averigüe cómo, entonces me interesa aprender a hacer programas que resuelvan dudas, avanzar en eso.

En resumen: ¿pará que se van a utilizar tales expresiones?

Las copiaré, y las pegaré en el código de un programa que intentará cumplirlas. Repetiré eso muchas veces. Me gustaría por ende que la expresión fuese llevada "al if" directamente, sin que yo tenga que copiarla y pegarla, pero eso es otro tema.
Quiero hacer un programa que cumpla condiciones cada vez más complejas. Hacer experimentos con eso. Evitar tener que idear y escribir yo condiciones a cada rato.

¿cuál es la últilidad práctica que han de tener?

Creo que ya respondí eso o más o menos...

así se podrá ver una forma óptima y elegante de crearlas.

Ojalá...

Si tapas el monte y solo muestras una hoja, no te ayudas a tí mismo.

Es que no lo veo necesario y quería mantener el hilo corto. Si hubiera spoiler... pero igual había dicho algo:
"Quiero el pseudocódigo de un programa que genere expresiones que no tengan paréntesis redundantes."

¿No alcanzaba? ¿realmente lo que agregué te sirvió de algo para responder?

[Serapis]

Bien... ahora te has expresado mejor... Así que sí, si sirvió que te explicaras.

Te voy aclarando cosas, pero no necesariamente por orden si no como me vengan a la cabeza (suelo escribir de corrido).

De entrada te diré que ya te puse en otro hilo que abriste un pseudocódigo, pero nuevamente lo pisaste como una alfombra, sin saber que lo estabas pisando... al final o mañana vuelvo a ello, segúin vea que sale de largo este mensaje.

Lo importante de mis preguntas eran dos o tres cosas:
- 1º para que las necesitabas... esto es, solo querías imprimrlas o bien al final tendrías que aplicarlas. Contestado, al final acabarás aplicándolas...
- 2º cuánto de largas podrían llegar a ser tales expresiones?. Esta te la preguntaba en otro hilo, y olvidé repetirla aquí. La razón que la ustifica es que aveces, si algo es breve, se resuelve más pronto a mano que generando un algoritmo efectivo. También porque si la cantidad es enorme, aplicarlas (o solo escribirlas a disco), podría llegar a tener tantas combinaciones que ni el disco tendría espacio suficiente, ni tu vida para verlas aparecer todas... depende de la cantidad... recuerda que hablamos de combinatoria a fin de cuentas.
- 3º Si no se iban a aplicar no tiene importancia ciertos detalles, si se van a aplicar, en cambio son otros detalles los que no importan.
- 4º El lenguaje en que vayas a programar, generalmente no importa... peor a este caso, creo que sí, porque desconozco realmente hasta que punto 'tu lenguaje' tenga las cosas encesarias o las facilidades para poder programarlas adecuadamente. En generla los lenguajes de script, se diseñan y crean para determinadas cuestiones específicas y siempre como soporte para un tipo de usuario centrado en una materia específica, que necesitan dominar, pero que no precisan se rprogramadores ni complicarse la vida más allá de lo que atañe a tales tareas... es decir viene contracorriente d elo que es un lenguaje "de propósito general"...
Luego al margen de las facilidades que provea 'tu lenguaje', se le puede sumar el problema del rendimiento... Los lenguajes de script, se diseñan como una utilidad añadida, y es raro que se busque en ellos el máximo rendimiento en el desempeño de su tarea. Pero bueno, esto es algo que ya tendrás ocasión de comprobar según lo complejo o largo que vayas a hacerlo... y siempre podrás adquieri un nuevo equipo, añadir memoria, o mejor cambiar de lenguaje. O quizás todo...

Al caso, gran parte de lo que necesitas encaja de pleno en la teoría de compiladores, pero como ya has demostrado tu nivel, será harto complejo explicarte como abordarle de la forma más óptima.

1 - Una forma sencilla de abordarlo y sin requerir paréntesis, es que generes dos operandos y los calcules, el resultado es un operando listo para ser operado con el siguiente operando generado.
Esta es la forma en que funciona una calculadora de mano simple.

A = A op B
A = A op C
A = A op D
'A', puede entenderse como 'acumulador', 'resultado' en una calculadora.
Y 'op' como el operando concreto que a cada momento se precise usar. El orden de ejecución será el que uno precise... aunque yo pongo B,C,D podría ser alterado
A = A op C
A = A op B
A = A op D

2 - Dicho de otro modo habrá tantos modos de órdenes (de ordenar los operandos) de ser ejecutado como el factorial de operandos que haya. El factorial es 1*2*3*4*5 es decir 5 variables pueden ordenarse de 120 maneras distintas, 6 de 720 (1*2*·*4*5*6*7), etc....

3 - Si usamos un solo operador son solo esas 120 expresiones distintas. Pero, nuevamente, aclaramos que la cantidad d eoperadores para n operandos siempre será n-1 operadores (el principio de la valla, cuantos postes se requierne para tender una alamabrada? 2 postes para una alambrada, y luego un poste por cada nueva alambrada, luego siempre hace falta 1 poste más que alambradas).
...con 5 operandos, en medio habrá 4 operadores. Nuevamente estos operadores pueden ser  ordenados de distintas formas... sigue la misma regla del factorial: 1*2*3*4 = 24 formas de ordenar los 4 operadores. Combinándolas con las 120 combinaciones posibles de operandos tendrás 120*24 = 2.880 expresiones.

4 - En este punto hay que observar que es evidente que habrá expresiones equivalentes "A = (B + C)" es equivalente a  "A = (C + B)" (solo hemos cambiado el orden de los operandos, pero el operador no altera el producto.

5 - Sin embargo dada la velocidad de cálculo, es preferible recalcularlas que intentar buscarlas para desecharlas... es menos costoso (creo que estamos hablando de operaciones buleanas... and or, xor... era así, no?).
Natualmente optar por esta solución (que gana en velocidad y ahorra en simpleza), a cambio dará redundancia de resultados (saldrán más resultados 'correctos' pero que son equivalentes).

6 - Bien, de hacer un filtrado de redundancia de expresiones equivalentes, es preferible hacerlo ahora, porque la cantidad de expresiones 'correctas' entre las que buscar equivalentes, será considerablemente menor que al comienzo con todas las combinaciones posibles. Es decir supongamos que de entre esas 2880 expresiones resultantes, 60 dan una respuesta 'correcta', buscar entre ellas las equivalentes entre sí, es considerablemente más breve (en tiempo de cálculo que hacerlo sobre las 2880.

7a - No estamos considerando paréntesis de momento. Y no lo haremos hasta que quede claro todo lo previo y considerar si de verdad los vas a necesitar. Esto es si hay problemas de rendimeinto, por la complejidad de las expresiones que nos lleve a reducir de entrada las expresiones únicas para ejecutar solo esas... mientras no se demuestre que esto sea más rápido que calcularlas, no veo la necesidad de introducir paréntesis... de ahí mi ahínco por preguntarte cuanto de largas (número de operandos) podrían llegar a tener las expresiones)... las buleanas se resuelven muy veloz porque son atómicas (están diseñadas en la UAL, no suelen requerir más de un ciclo de reloj y según el procesador puede ejecutar en paralelo varias instrucciones).
7b - Porque como ya te he dicho antes, si vas operando sobre la marcha y consideras las combinatoria de los operandos y de los operadores, no necesitas paréntesis porque acabas por ejecutar todas las expresiones posibles.

Y de momento lo dejo aquí esperando haberme hecho entender... y si es conforme que haya entendido correctamente tus necesidades dada tu explicación previa de lo que haces (exiges que haga el programa).

Y con lo que me digas si falta algo lo vemos y si no avanzamos derivando por un lado o por otro... Esto es, he puesto 7 puntos espero que todos y cada uno de ellos te hayan quedado claros, por eso los he marcado, para que no lo pises como si fueran invisibles.

[Tachikomaia]

Disculpa la demora, a veces me canso de estas cosas o no tengo ganas en el momento, queda para mañana y así, qué sé yo.

Algo que debo aclararte es que si bien me será útil obtener condiciones random, también voy a necesitar que se generen listas (eso cuando necesito poner una condición en un lado y no sé cual sería; equivale a usar fuerza bruta en la que el candidato no sería un número sino una condición). Olvidé eso. Listas es como esto:
https://www.geeksforgeeks.org/possible-strings-length-can-formed-given-string/

Bien... ahora te has expresado mejor... Así que sí, si sirvió que te explicaras.

Sigo teniendo mis dudas.

De entrada te diré que ya te puse en otro hilo que abriste un pseudocódigo, pero nuevamente lo pisaste como una alfombra, sin saber que lo estabas pisando...

He revisado este tema
https://foro.elhacker.net/programacion_general/duda_sobre_expresiones_condicionales-t485203.10.html
2 veces (la pág 3 sólo 1 vez) pero no sé a qué te refieres. Tal vez no pusiste el pseudo sino que mencionaste un algoritmo. Eso no lo revisé. No sé. Recuerdo que alguien me dijo una función, quizá tú, pero no lo encontré.

Lo importante de mis preguntas eran dos o tres cosas:
- 1º para que las necesitabas... esto es, solo querías imprimrlas o bien al final tendrías que aplicarlas. Contestado, al final acabarás aplicándolas...

Pero es lo de menos. Lo importante es que se impriman las que necesito y las pueda copiar. Lo demás es para más adelante. Si a copiarlas y pegarlas le quieres llamar "aplicarlas", bueno, también es eso, por ahora.
En fin, yo te sigo la corriente, pero me parece que en este sentido complicaste el tema innecesariamente.

- 2º cuánto de largas podrían llegar a ser tales expresiones?

Depende de cual sea el problema más complejo que yo logre resolver. En teoría, lo que el programa aguante, no sé, nunca me pasó que se trancara por exceso de información (sí por loops o en Clipper porque el programa al compilarlo pesaba mucho, pero era otra cosa, un juego).

aveces, si algo es breve, se resuelve más pronto a mano que generando un algoritmo efectivo.

Bueno, ya te expliqué que a la larga me convendría el code.

También porque si la cantidad es enorme, aplicarlas (o solo escribirlas a disco), podría llegar a tener tantas combinaciones que ni el disco tendría espacio suficiente, ni tu vida para verlas aparecer todas...

Estoy muy lejos de querer guardar una lista (sólo en la pantalla del output...) y no tengo interés en verlas todas.

- 3º Si no se iban a aplicar no tiene importancia ciertos detalles, si se van a aplicar, en cambio son otros detalles los que no importan.

No imagino del todo de qué hablas. Si me dices un poco más, gracias.

- 4º El lenguaje en que vayas a programar, generalmente no importa... peor a este caso, creo que sí, porque desconozco realmente hasta que punto 'tu lenguaje' tenga las cosas encesarias o las facilidades para poder programarlas adecuadamente.

En general siempre tuve todo lo que necesité. Lo que no tiene por ejemplo es "figuras" para hacer las detecciones de colisiones más exactas. Acá todo es rectangular o cuadrado. Tampoco tiene, creo, la función para obtener el resto de una división, pero se puede hacer. En fin, no sé qué decirte.

se le puede sumar el problema del rendimiento...

Tiene algunos, pero es largo de explicar y no viene mucho al caso (los problemas que yo conozco, otros puede que sí).

y siempre podrás adquieri un nuevo equipo, añadir memoria

He tenido problemas al hacer juegos, pero en esto no creo. Es sólo texto...
No tengo dinero ni mucho interés en toquetear mi machine.

o mejor cambiar de lenguaje.

Difícil pero supongo que no imposible.

Al caso

Al fin.

gran parte de lo que necesitas encaja de pleno en la teoría de compiladores, pero como ya has demostrado tu nivel, será harto complejo explicarte como abordarle de la forma más óptima.

Alguien me recomendó que haga "el árbol" o algo así, pero leí en wikipedia y no entendí. Sí recuerdo que hablaba de compiladores.

1 - Una forma sencilla de abordarlo y sin requerir paréntesis, es que generes dos operandos y los calcules, el resultado es un operando listo para ser operado con el siguiente operando generado.
Esta es la forma en que funciona una calculadora de mano simple.

A = A op B
A = A op C
A = A op D
'A', puede entenderse como 'acumulador', 'resultado' en una calculadora.
Y 'op' como el operando concreto que a cada momento se precise usar. El orden de ejecución será el que uno precise... aunque yo pongo B,C,D podría ser alterado
A = A op C
A = A op B
A = A op D

No estoy entendiendo.

Mira, he hecho este código:

Código [Seleccionar] Expandir

SC1P1 = 1;
SC1P2 = 1;
SC1P3 = 0;
Op1 = " < ";
Op2 = " <= ";
Op3 = " == ";
Op4 = " != ";
Op5 = " > ";
Op6 = " => ";
function PassorPrint () {
    if (SC1P1<SC1P3) {
        if (SC1P2<5) {
            trace ("V"+SC1P1+eval("Op"+SC1P2)+"V"+SC1P3);
        } else {
            trace ("V"+SC1P3+eval("Op"+(SC1P2-4))+"V"+SC1P1);
        }
    }
}
do {
    if (SC1P3<2) {
        SC1P3 = SC1P3+1;
        PassorPrint();
    } else {
        SC1P3 = SC1P1;
        if (SC1P2<6) {
            SC1P2 = SC1P2+1;
            PassorPrint();
        } else {
            SC1P2 = 1;
            SC1P1 = SC1P1+1;
            PassorPrint();
        }
    }
} while (SC1P1<2);

Este es el output:
V1 < V2
V1 <= V2
V1 == V2
V1 != V2
V2 < V1
V2 <= V1

Sólo eso, sí. Tendría que hacer un código que genere condiciones compuestas por más subcondiciones (SC), estoy en eso.

¿Ese output tiene que ver con lo que me estás diciendo? Cuando haya más SC tendré que ponerles paréntesis. Me dices que "sin usar paréntesis" entonces m...

2 - Dicho de otro modo habrá tantos modos de órdenes (de ordenar los operandos) de ser ejecutado como el factorial de operandos que haya. El factorial es 1*2*3*4*5 es decir 5 variables pueden ordenarse de 120 maneras distintas, 6 de 720 (1*2*·*4*5*6*7), etc....

Bien...

3 - Si usamos un solo operador son solo esas 120 expresiones distintas. Pero, nuevamente, aclaramos que la cantidad d eoperadores para n operandos siempre será n-1 operadores (el principio de la valla, cuantos postes se requierne para tender una alamabrada? 2 postes para una alambrada, y luego un poste por cada nueva alambrada, luego siempre hace falta 1 poste más que alambradas).

Ok...

...con 5 operandos, en medio habrá 4 operadores. Nuevamente estos operadores pueden ser  ordenados de distintas formas... sigue la misma regla del factorial: 1*2*3*4 = 24 formas de ordenar los 4 operadores. Combinándolas con las 120 combinaciones posibles de operandos tendrás 120*24 = 2.880 expresiones.

No sé si te estoy siguiendo, pero una cosa son lo operadores de comparación y otros los que relacionan (and y or). xor puede ser también, aún no lo estudié.

4 - En este punto hay que observar que es evidente que habrá expresiones equivalentes "A = (B + C)" es equivalente a  "A = (C + B)" (solo hemos cambiado el orden de los operandos, pero el operador no altera el producto.

m...... Probablemente no lo había aclarado pero, por ahora no quiero que haya operaciones en las condiciones, sólo Variable, comparador, variable, relacionador, etc.
No sé si lo que estás haciendo contradice eso. Si estás planeando poner operaciones me serviría, pero comencemos por lo sencillo.

5 - Sin embargo dada la velocidad de cálculo, es preferible recalcularlas que intentar buscarlas para desecharlas... es menos costoso

No entendí.

(creo que estamos hablando de operaciones buleanas... and or, xor... era así, no?).

Así es.

Natualmente optar por esta solución (que gana en velocidad y ahorra en simpleza), a cambio dará redundancia de resultados (saldrán más resultados 'correctos' pero que son equivalentes).

Quiero evitar redundancias...

6 - Bien, de hacer un filtrado de redundancia de expresiones equivalentes, es preferible hacerlo ahora, porque la cantidad de expresiones 'correctas' entre las que buscar equivalentes, será considerablemente menor que al comienzo con todas las combinaciones posibles. Es decir supongamos que de entre esas 2880 expresiones resultantes, 60 dan una respuesta 'correcta', buscar entre ellas las equivalentes entre sí, es considerablemente más breve (en tiempo de cálculo que hacerlo sobre las 2880.

¿Puedes encontrarlas sin filtro? m...

7a - No estamos considerando paréntesis de momento. Y no lo haremos hasta que quede claro todo lo previo y considerar si de verdad los vas a necesitar.

Phew.

Esto es si hay problemas de rendimeinto, por la complejidad de las expresiones que nos lleve a reducir de entrada las expresiones únicas para ejecutar solo esas... mientras no se demuestre que esto sea más rápido que calcularlas, no veo la necesidad de introducir paréntesis...

¿?

7b - Porque como ya te he dicho antes, si vas operando sobre la marcha y consideras las combinatoria de los operandos y de los operadores, no necesitas paréntesis porque acabas por ejecutar todas las expresiones posibles.

Se supone que lo has entendido, pero... necesito generar las expresiones posibles. ¿Cómo, sin paréntesis, podrías generar esto "(V1<V2 o V1<V3) y V1<V4"? Tú mismo me decías en otro tema que no se puede vivir sin paréntesis. En fin, tú sabrás lo que haces...

Y de momento lo dejo aquí esperando haberme hecho entender... y si es conforme que haya entendido correctamente tus necesidades dada tu explicación previa de lo que haces (exiges que haga el programa).

¡Pero cuánto protocolo hombre!

Y con lo que me digas si falta algo lo vemos y si no avanzamos derivando por un lado o por otro... Esto es, he puesto 7 puntos espero que todos y cada uno de ellos te hayan quedado claros, por eso los he marcado, para que no lo pises como si fueran invisibles.

No los memoricé pero sí los leí y opiné como has visto, pero me parece que te complicas mucho. De momento me serviría que hagas un código como el que yo hice, pero que en vez de producir condiciones de 1 subcondicion, sean de 2, o sea: V op V rel V op V
El output debería ser algo así:
V1 < V2 && V1 < V3
V1 < V2 && V1 <= V3
V1 < V2 && V1 == V3
V1 < V2 && V1 != V3
V1 < V2 && V3 < V1
V1 < V2 && V3 <= V1
V1 < V2 && V2 < V3
...
V1 < V2 && V4 < V3
Nota: V4 no es un error. Pero sólo hay V4 si en la misma condición hay otras 3.
...
V1 < V2 or V1 < V3
...
V1 < V2 or V4 < V3
V1 < V3 or V1 < V2 <-- Esta creo que es repetida, debe evitarse.

Por ahora es lo que intento hacer.

Tengo este código que sería un intermedio entre el código que antes te puse, y el que quiero hacer.

Código [Seleccionar] Expandir

// Partes de la subcond.
SC1P1 = 1;
SC1P2 = 1;
SC1P3 = 0;
// Cosas para evitar ifs.
Op1 = " < ";
Op2 = " <= ";
Op3 = " == ";
Op4 = " != ";
Op5 = " > ";
Op6 = " => ";
CursorMax1 = 2;
CursorMax2 = 6;
CursorMax3 = 2;
Reset2 = 1;
Reset3 = SC1P1;
// Otras cosas.
Cursor = 3;
function PassorPrint () {
    if (SC1P1<SC1P3) {
        if (SC1P2<5) {
            trace ("V"+SC1P1+eval("Op"+SC1P2)+"V"+SC1P3);
        } else {
            trace ("V"+SC1P3+eval("Op"+(SC1P2-4))+"V"+SC1P1);
        }
    } else {
        Reset3 = SC1P1;
    }
    Cursor = 3;
}
do {
    if (eval("SC1P"+Cursor)<eval("CursorMax"+Cursor)) {
        set ("SC1P"+Cursor, eval("SC1P"+Cursor)+1);
        PassorPrint();
    } else {
        set ("SC1P"+Cursor, eval("Reset"+Cursor));
        Cursor = Cursor-1;
    }
} while (SC1P1<2); Si lo consideras confuso e ineficiente, concuerdo xD Pero por ahora es lo que tengo.

Gracias.