Errores, fallos, preguntas - página 739

Nuevo comentario
 
ivandurak:

Optimizar por campos de bits, no habrá pases innecesarios en esta variante.

Por ejemplo:

input int bp=0;
int a=0;
int b=0;
Start()
{
 switch(bp)
   {
    case 0: a=0; b=0; break;
    case 1: a=0; b=1; break;
    case 2: a=1; b=0; break;
    default: a=1; b=1; break;    
   }
}

y optimizar en parámetros dados, para este ejemplo se optimiza bp de 0 a 3

 
ivandurak:
Sólo que usted se olvidó de escribir el veredicto si puede o no puede.
No he olvidado nada :) Si hubiera sabido exactamente cómo hacerlo, se lo habría dicho. Es un poco presuntuoso dar un veredicto negativo, porque no conocer la solución no significa que no la haya.
 
Entiendo la idea. Me pregunto si la genética se volverá loca por semejante truco. Resulta que, en principio, un conjunto de parámetros de trabajo da un resultado nulo y no interviene en la selección posterior. Imho mejor en los deseos de methaqvoters escribir algo así como los parámetros optimizables relacionados, si es falso, entonces no debe ser anulado.
 
Yedelkin:

¿Cómo puede ser "más fácil"? :) Las condiciones para borrar un EA o para REASON_INITFAILED todavía tienen que ser seguidas. Esto es lo que parece una molestia.

Si no hay una solución elegante, se puede utilizar primero la que sea más "fácil". Encuentra algo mejor, siempre puedes sustituirlo. :)
 
ivandurak:
Resulta que, en principio, un conjunto de parámetros de trabajo da resultados nulos y no interviene en la selección posterior.
En realidad no, si hablamos de mi tortuosa idea. Con el "conjunto de parámetros de trabajo" y la primera pasada de trpar2=false dará un resultado que funciona bastante bien. Todos los pases posteriores con el mismo "conjunto de parámetros de trabajo" y trpar2=false devolverán inmediatamente cero, pero su "conjunto de parámetros de trabajo" participará en la selección de todos modos y los pases duplicados serán rechazados. Esto es lo que querías, ¿no?
 
tol64:
A falta de una solución elegante, puedes utilizar primero la más "fácil". Si se encuentra algo mejor, siempre se puede sustituir. :)
Una vez más: el problema no es qué comando para terminar el pase antes de tiempo - es solución bastante primitiva, sea lo que sea. La coyuntura - en el seguimiento de las condiciones para la pronta finalización del paso. El "bloque de seguimiento" no disminuye, y la elegancia de este bloque no aumenta de ninguna manera.
 
Yedelkin:
En realidad no, si te refieres a mi tortuosa idea. Con el "conjunto de parámetros de trabajo" y el primer trpar2=false el pase dará un resultado bastante funcional. Todos los demás pases con el mismo "conjunto de parámetros de trabajo" y trpar2=false devolverán inmediatamente cero, pero su "conjunto de parámetros de trabajo" participará en la selección de todos modos. Esto es lo que querías, ¿no?

Puedes corregirlo un poco. Los parámetros de optimización deben escribirse en estructuras, y éstas (las estructuras simples) deben tratarse como variables. El código debe decir

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aquí Par y Parold son estructuras en las que se escriben los parámetros óptimos de otros pares de divisas. Por muchos pares que haya si, no se ve tan feo. Gracias.

 
Yedelkin:
Una vez más: la molestia no tiene que ver con la orden de terminar el pase antes de tiempo - esta es una solución bastante primitiva, sea cual sea. La molestia está en seguir las condiciones para completar el pase antes de tiempo. El hecho de que el paso se completará antes de tiempo con la ayuda de su sugerencia, "unidad de seguimiento" en sí no es menos molesto, y la elegancia de esta unidad no se incrementa de ninguna manera.

¿Qué quieres decir con eso? ¿Que, a falta de una solución elegante, no hay que utilizar ninguna? Incluso si hay uno, pero, como dices, "doloroso"?

En resumen, sigamos adelante. De lo contrario, es más molesto por la inundación que por el código. :)

 
ivandurak:

Puedes corregirlo un poco. Los parámetros de optimización deben escribirse en estructuras, y éstas (las estructuras simples) deben tratarse como variables. El código debe decir

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aquí Par y Parold son estructuras en las que se escriben los parámetros óptimos de otros pares de divisas.

Sí, algo así. Sólo resulta que tendremos que recordar TODOS los "conjuntos de parámetros de trabajo" que colisionaron con trpar2=false. Es decir, el conjunto de estructuras correspondientes se ampliaría enormemente. Además habrá que guardarlo en archivo para leerlo recordado en la nueva pasada.
 
ivandurak:

Puedes corregirlo un poco. Los parámetros de optimización deben escribirse en estructuras, y éstas (estructuras simples) deben tratarse como variables. El código debe decir

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Aquí Par y Parold son estructuras en las que se escriben los parámetros óptimos de otros pares de divisas. Por muchos pares que haya si, no se ve tan feo. Gracias.

Hay una variante más (se me ha olvidado).

Puedes echar un vistazo a las funciones: OnTesterInit(), OnTesterPass(), OnTesterDeinit().

Y FrameFirst (),FrameFilter (),FrameNext (),FrameInputs (),FrameAdd().

Para eso están exactamente. :)

Es decir, siempre se pueden solicitar todos los parámetros de cualquier pase en la optimización actual en cualquier momento.

1...732733734735736737738739740741742743744745746...3187
Nuevo comentario