¿Es posible evitar muchas "ores" (||) en las condiciones que provocan la misma acción? - página 3

[Alexey Subbotin]

alsu:
Podemos acelerar más, por ejemplo, si sabemos que la condición A se satisface de media más a menudo que la C y la C más a menudo que la B, entonces deberíamos ponerlas en ese orden: if(!a){if(!c)if{(!b) M=false;}}

Se pueden acelerar aún más las cosas combinando la probabilidad de una condición con su complejidad computacional: por ejemplo, tomando como criterio el producto de la probabilidad de que se produzca por el valor inverso del tiempo de computación, las primeras condiciones que se comprueban son las más probables y con menor complejidad computacional, es decir, las que tienen el valor más alto de nuestro criterio dado.

[Boris]

TarasBY:

También puede optimizar los cálculos de esta manera:

O tal vez podrías intentarlo de esta manera:

    bool M = false;

    if (A) M = true; else if (B) M = true; else if (C) M = true; else if (D) M = true; else if (E) M = true;
    if (M == true) Action;

Gracias.

[Boris]

alsu:

Se pueden acelerar aún más las cosas combinando la probabilidad de una condición con su complejidad computacional: por ejemplo, tomando como criterio el producto de la probabilidad de ejecución por un valor inverso del tiempo de computación, se comprueban primero las condiciones que son más probables y tienen la menor complejidad computacional, es decir, las que tienen el valor más alto de nuestro criterio dado.

Los puse en ese orden hace mucho tiempo. Pero incluso si se cumple más de una condición, se cumplirá la primera que aparezca.

Y no importa, porque entonces las condiciones finales son comunes para todas las variantes.

[Boris]

alsu:

Se pueden acelerar aún más las cosas combinando la probabilidad de una condición con su complejidad computacional: por ejemplo, tomando como criterio el producto de la probabilidad de ejecución por el valor inverso del tiempo de computación, se comprueban primero las condiciones que son más probables y tienen la menor complejidad computacional, es decir, las que tienen el valor más alto del criterio que hemos establecido.

Alexey, una vez más respondo a tu sugerencia de intercambiar las condiciones en función de su influencia en la velocidad de ejecución de las acciones. Y esto es lo que he encontrado. Los cálculos más complejos no son tan lentos como las funciones que comprueban varios datos necesarios del mercado y las posiciones abiertas para cada tick. Ya he simplificado bastante estas funciones por consejo de uno de los usuarios del foro, desechando todas las cosas innecesarias en mi caso, lo que casi ha duplicado su velocidad. En cuanto a la elección de trabajar en "cada" garrapata, antes estaba convencido de que sólo este modo me acerca a los posibles resultados reales. Así pues, al haber implementado estas funciones después de todos los cálculos, las comprobaciones de los indicadores y las comprobaciones de los precios actuales, la velocidad se ha duplicado, lo que hace que ahora haya 7 minutos de funcionamiento en el probador durante medio año y 14 minutos al año respectivamente. No puedo renunciar a las funciones que realizan las comprobaciones necesarias, si las condiciones anteriores lo permiten. Ahora intentaré optimizar el código cambiando && por ) si (. Estaré encantado de saber qué otras posibilidades de optimización del código existen. Gracias a ti y a todos por vuestra ayuda.

[[Eliminado]]

borilunad:

Ninguno de los operadores encaja. ¿Existe otra forma sin la acción if(A || B || C || D || E)?

¡Pido a los moderadores que no envíen al hilo de preguntas generales debido a la importancia de la pregunta que estoy pensando y no puedo encontrar una solución más racional! Gracias.

if(A || B || C || D || E)Acción;yo haría estoif((A + B + C + D + E) > 0) Acción; sila Acción necesita al menos 3 señales, escribe 2 en lugar de 0

la velocidad, no la he medido.

[Victor Nikolaev]

pako:

if(A || B || C || D || E)Acción;yo haría estoif((A + B + C + D + E) > 0) Acción; sila Acción necesita al menos 3 señales, escribe 2 en lugar de 0

velocidad, no he medido

La velocidad sería tremenda. La solución es muy original

[Sergey Fionin]

Si A,B,C,D son funciones, debes contar por orden de complejidad, empezando por la más fácil y comprobando constantemente su veracidad. Esto funcionará más rápido.

[Boris]

Vinin:

La aceleración será tremenda. La solución es muy original.

¡Acaba de llegar! ¡Gracias, Pako! ¡Gracias, Víctor! Voy a almorzar ahora y a probarlo.

[Boris]

FION:
Si A,B,C,D son funciones, hay que contar por complejidad, empezando por la más fácil, y comprobar constantemente la veracidad. Así funcionará más rápido.

Gracias por su participación. A, B, C ... no funciones, sino condiciones que contienen funciones y que no contienen funciones, ¡y además se excluyen mutuamente! Y una condición es suficiente para saltar a otras condiciones que ya desencadenan la acción. Si sólo hubiera funciones, no habría problema:

doble A = función1(); doble B = función2(); doble C = función3(); doble D = función4(); doble E = función5(); y luego como sugirió Pako:

si((A + B + C + D + E) > 0)

{otra condición con dirección reflejada para cerrar la acción de Byes o Sells};PERO:

Y necesito A = condición1, B = condición2, C = condición3, D = condición4, E = condición5. ¿Es posible o no? ¿O es imposible y ya está?

Por ejemplo:

bool a = true;

//или
double a;

а = (isCloseLastPosByTake() == True && Profit > ProClo / clo - GetProfitCloseLastPosByTake() * clo);

¡No sé qué probar!

[[Eliminado]]

borilunad:

Y necesito A = condición1, B = condición2, C = condición3, D = condición4, E = condición5. ¿Es posible o no? ¿O es imposible y ya está?

bool a = true;

//или
double a;

а = (isCloseLastPosByTake() == True && Profit > ProClo / clo - GetProfitCloseLastPosByTake() * clo); <---   10,444 = 8,087 > 3,908 эт на каком языке? 

bool a = false;

if (isCloseLastPosByTake() == True && Profit > ProClo / (clo - GetProfitCloseLastPosByTake() * clo)) a = true;