prev_calculado - página 10
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
No lo hace. Habrá un corte de conexión de varias barras, varias barras estarán sin inicializar con basura.
O bien, como dijo Dmitry más arriba, hubo una interrupción de la conexión de varios compases... Por cierto, ¿también prev_calculated devolverá 0 en caso de fallo de la conexión?
Al parecer, en ese momento sí hubo una interrupción de la comunicación.
2016.10.19 04:45:37.260 Network '4092672': scanning network for access points
2016.10.19 04:45:36.630 Network '4092672': trading has been enabled - hedging mode
2016.10.19 04:45:36.630 Network '4092672': terminal synchronized with MetaQuotes Software Corp.
2016.10.19 04:45:36.000 Network '4092672': previous successful authorization performed from 31.173.80.3 on 2016.10.18 17:51:14
2016.10.19 04:45:36.000 Network '4092672': authorized on MetaQuotes-Demo through Access Point SG Singapore (ping: 583.86 ms)
2016.10.19 04:42:57.680 Network '4092672': connection to MetaQuotes-Demo lost
Y lo más probable es que cuando haya una interrupción, prev_calculated devuelva 0.
Vale, ha sido una pausa larga, pero ¿qué ha provocado los otros nulos prev_calculados?
De estas líneas.
2016.10.18 23:51:20.865 Network '4092672': scanning network for access points
Hasta los anteriores no hay más registros que los comerciales como éste.
Y puedes ver la cantidad de ceros de prev_calculado que había en mi post anterior.
Potencialmente, la culpa podría estar aquí:
{
minEquity = 0;
maxEquity = 0;
}
minEquity = NormalizeDouble(fmin((minEquity == 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Cuando llega una nueva barra, se restablecen los valores a 0 - bien. Pero entonces se comprueba la igualdad de minEquity y 0, lo que no es recomendable.
Para demostrar mis palabras, aquí está su imagen. Puedes ver que los valores de la "basura", como has dicho, son aproximadamente cero.
Por supuesto, es mejor añadir una ventana de datos en la imagen con el valor de "basura".¿Puede explicar por qué no se recomienda este método?
Esta parte del código (minEquity == 0? bal : minEquity), si minEquity == 0, devolverá el valor de bal que se obtuvo anteriormente; el valor de minEquity no cambiará hasta que la función fmin() termine.
Aunque estoy de acuerdo en que este tipo de escritos son un poco arriesgados... pero ese no es el problema.
¿Puede explicar con más detalle por qué no se recomienda este método?
esta parte del código (minEquity == 0? bal : minEquity), si minEquity == 0, devolverá el valor de bal obtenido anteriormente; el valor de minEquity no cambiará hasta que la función fmin() termine
Aunque estoy de acuerdo en que esta forma de escribir el código es un poco arriesgada... pero ese no es el problema.
Me refería específicamente a esto: minEquity ==0. Estás comparando en la igualdad de los números dudosos. Eso podría explicar la caída de los valores a 0.
Ya veo, la respuesta correcta es minEquity ==0.0 ... No puedo acostumbrarme a ello.
Y la última frase no la entiendo en absoluto. ¿Qué valores a 0?
Ya veo, la respuesta correcta es minEquity ==0,0 ... No puedo acostumbrarme a ello.
Y la última frase no la entiendo en absoluto. ¿Qué valores a 0?
Pero no sé si una conversión de tipos implícita puede causar un error. Me refería a la comparación de tipos reales. Es decir, aquí, para estar seguro, lo escribiría así:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Sin embargo, no sé si una conversión de tipos implícita puede provocar un error, yo hablaba, en principio, de comparar tipos reales. Por ejemplo, en este caso, para que sea fiable, lo escribiría así:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Sí, mi versión cuenta el dinero con dos decimales. Esto no es una cita, así que no se puede ser tan preciso al respecto.
No es una cuestión de meticulosidad, sino de precisión. En su caso, podría resultar en un valor cero que se escribe en el buffer. Si no quieres tanta precisión, hazlo así:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Entonces no habrá ningún error.
No es una cuestión de meticulosidad, sino de precisión. En su caso, podría resultar en un valor cero que se escribe en el buffer. Si no quieres esa precisión, hazlo así:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
En ese caso no habrá error.
¿Por qué soy tan estúpido? ¿Cómo no he adivinado que es mejor inicializar minEquity con un valor distinto de cero? Entonces todo será más fácil...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
También puede utilizar maxEquity = DBL_MIN;
¿Por qué soy tan estúpido? ¿Cómo no he adivinado que es mejor inicializar minEquity con un valor distinto de cero? Entonces todo sería más fácil...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Bueno... O así...