----
Actualmente tengo la descripción así:
Sección 1-
Nro de la condición___Elemento 1___Comparador___Elemento 2
1___________________A__________==__________B
2___________________A__________>___________C
O sea, son columnas y filas, estilo Excel, aunque por ahora sólo 2 filas. Los datos en ellas son un ejemplo, el usuario podría cliquearlos y se abrirían ventanas donde podría modificarlos. Pero el nro indica también el nro de la fila, se establece automáticamente. Los elementos son como nombres de las variables.
Sección 2-
Nro de la relación__1
Condición 1_______1
Relación_________&&
Condición 2_______2
En cuanto al orden, estructura o como se diga, esto es al revés a lo anterior: Los datos se ponen en las columnas. Por ahora sólo hay una así.
El nro funciona más o menos como el caso anterior. En cuanto a lo demás, son los números o IDs de la sección anterior, separados por la relación entre ellos.
Sección 3-
Nro de la relación en que se producen los cambios.
Cambios especificados aquí hacia abajo.
La descripción de los cambios no es el tema. El nro aquí se basa en la sección anterior.
La aplicación, o sea, el código "para que funcione", por ahora lo tengo así:
Código:
La verdad hace bastante que no pienso en ese código y me resulta complicado, así que no pongo las manos en el fuego ni siquiera en cuanto a su coherencia (de funcionamiento ni hablar). Algunas cosas en él pueden mejorarse, pero bueno, no es el tema. Lo puse porque la cuestión del tema requiere que pueda codificarse, o sea hacer que la cosa funcione. La cuestión es que el usuario pueda describir condiciones y qué se hace en ellas, y que el programa funcione de esa forma. Uds pueden recomendarme que haga esto o aquello, yo mismo tengo ideas, pero si codificarlas es extremadamente difícil, entonces no me serviría mucho por ahora. Por eso hice énfasis en que funcione.// Cams
Oks = 0;
// Condiciones cumplidas.
OksReq = 1;
// Condiciones requeridas.
A = 0;
do {
A = A+1;
// Nro de cambio a chequear.
B = eval("Cam"+A+"Cond");
// Condición del cambio.
C1 = eval("Grup"+B+"Cond1");
// ID de la condición 1 en la relación de condiciones.
// Partes de la condición 1:
C1A1 = eval("Cond"+C1+"Elm1");
C1C = eval("Cond"+C1+"Comp");
C1A2 = eval("Cond"+C1+"Elm2");
// Relación:
D = eval("Grup"+B+"Rel");
// ID de la condición 2 en la relación de condiciones.
C2 = eval("Grup"+B+"Cond2");
// Partes de la condición 2:
C2A1 = eval("Cond"+C2+"Elm1");
C2C = eval("Cond"+C2+"Comp");
C2A2 = eval("Cond"+C2+"Elm2");
// Si la relación es “&&”, el nro de condiciones requerido es 2:
if (D == "&&") {
OksReq = 2;
}
if (C1C == "==") {
// Si la comparación es “==”
if (C1A1 == C1A2) {
// Si los elementos de la condición 1 son iguales,
// aumentan las condiciones cumplidas
Oks = Oks+1;
}
}
// Esto es para la condición 2.
if (C2C == "==") {
if (C2A1 == C2A2) {
Oks = Oks+1;
}
}
// Si las condiciones cumplidas son iguales o más que las condiciones requeridas
if (Oks>=ReqOks) {
// Iniciar cambios.
}
} while (A<Cams);
Ahora, si no lo han hecho ya, los invito a buscar fallas o limitaciones en el sistema de descripción. Entonces pasaremos a la cuestión de cómo mejorarlo.
¿Listo?
Ok, diré fallas que yo veo:
- En la sección 1 son sólo 2 líneas, deberían ser más.
>>> No es posible hacer operaciones entre las variables (*).
>>> No es posible poner paréntesis.
- En la sección 2 es sólo 1 línea, idem.
>>> No es posible hacer relaciones entre más de 2 condiciones (**).
- Es molesto andar cambiando de secciones, es un clic extra y todo...
- Es molesto tener que memorizar o rever los ID de cada condición y relaciones.
(*): No es posible decir, por ejemplo, Math.floor(A) == A, ni tampoco A+B == C
(**): No es posible decir, por ejemplo, 1 && 2 && 3
Las que puse con >>> son las que me importan por ahora. Con las demás creo que podré manejarme o son los efectos no deseados y posiblemente inevitables de un remedio (***), por ahora me resulta secundario.
(***): La "enfermedad" era "tener que reescribir condiciones".
Ok, el tema de los operadores y paréntesis lo estoy dejando para más adelante. La cuestión entonces son las relaciones.
Pero lo que me preocupa no es tanto que puedan ser más, sino cómo se interpretarían.
Esto:
(A == B && B == C) or A>C
no sería lo mismo que esto:
A == B && (B == C or A>C)
Supongo que la compu tiene una interpretación por convención, al igual que las ecuaciones con esas reglas de * y / se aplican antes que + y -, todo en pos de que todo lo pensable pueda ser aplicado. En el caso de las ecuaciones no sé para qué los matemáticos lo hicieron así, lo aprendí y así lo usé, pero en el caso que nos compete quiero saber cuales serían los motivos de la convención si es que la/los hay, más allá de evitar que cada uno interprete diferente.
Además, tengo cierto "temor" de que si se interpreta de una forma entonces sería imposible expresar la otra.
Veamos. Para el 1er caso podría usar un if y un else if (***). Para el 2ndo podría usar un if y luego otro if dentro. No hay problema, pero con esas, con otras no sé.
(***): Pero hay que escribir 2 veces el mismo efecto.
So. Agradezco sugerencias y aclaraciones sobre estos asuntos.
Los símbolos de las relaciones no tienen por qué ser los mismos que se usan en los lenguajes de programación. De hecho un poco lo que pienso es crear alguno, porque quiero evitar los paréntesis, ellos me obligarían a crear más columnas en la descripción y complicarían bastante la interpretación en código.
También he pensado que sería necesario un símbolo que diga "pero no":
(A && B) pero no C
A && (B pero no C)
Por cierto en ese caso es lo mismo independientemente de dónde se pongan los paréntesis.
Supongo que dicho símbolo existe, pero bue, nunca lo usé... Para casos como este habría usado "si no C, entonces si A && B...".
En pos de ver en imágenes las posibles condiciones, he pensado en hacer representaciones al estilo conjuntos, fue lo que se me ocurrió. Es decir, quiero ver las posibilidades, y no parece cuestión de hacer combinatoria porque, como acabo de decir, algunas son lo mismo a pesar de las diferencias. Mis representaciones consisten en escribir 1 2 3 y hacer un circulo que encierre a las condiciones requeridas. Si hay 2 formas de validar entonces habrá 2 circulos. And so on. Pensé que no servía en casos complicados, pero acabo de ver uno y se me ocurrió una forma que ayer no. Cosas que pasan, aún así les dejo el método por si alguno me puede decir uno mejor. Para los casos "pero no" he pensado en poner, debajo del 1 2 3, x1 x2 x3. Y bueno el circulo encerraría uno u otro según el caso. Si no encierra alguno entonces esa condición sería irrelevante. Pero ese método no he probado mucho que sirva.
Gracias.
