Dmitry Fedoseev: Não tem. Haverá uma quebra de conexão de várias barras, várias barras serão desinicializadas com lixo.
Alexey Kozitsyn: Ou, como Dmitry disse acima, houve uma quebra de conexão de várias barras. A propósito, será que o retorno pré-calculado será 0 também em caso de falha de conexão?
Aparentemente, houve de fato uma quebra na comunicação neste momento.
2016.10.19 04:46:13.770 Network '4092672': scanning network finished 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
E é mais provável que, quando há uma pausa, os retornos pré_calculados 0.
OK, foi uma longa pausa, mas o que causou os outros nulos pré_calculados?
Quando uma nova barra chega, você repõe os valores para 0 - multa. Mas então você verifica minEquidade e 0 para igualdade, o que não é recomendado.
Para provar minhas palavras, aqui está a sua imagem. Você pode ver que os valores do "lixo", como você disse, são cerca de zero.
É claro, é melhor acrescentar uma janela de dados na imagem com o valor "lixo".
Você pode explicar por que este método não é recomendado?
Esta (minEquity == 0? bal : minEquity) parte do código, se minEquity == 0, retornará o valor do bal que foi obtido anteriormente; o valor do minEquity não mudará até que a função fmin() termine.
Embora eu concorde que tal escrita é um pouco arriscada. mas esse não é o problema.
Você pode explicar com mais detalhes por que este método não é recomendado?
esta (minEquity == 0? bal : minEquity) parte do código, se minEquity == 0, retornará o valor do bal obtido anteriormente; o valor do minEquity não mudará até que a função fmin() termine
Embora eu concorde que esta forma de escrever o código é um pouco arriscada. mas esse não é o problema.
Eu estava falando especificamente sobre isto: minEquity ==0. Você está se comparando a números iguais de duplas. Isto pode explicar a queda nos valores para 0.
Alexey Kozitsyn: Eu estava falando especificamente sobre isto: minEquity ==0. Você está comparando sobre a igualdade dos números do duble. Isso pode explicar a queda nos valores para 0.
Vejo que a resposta correta é minEquity ==0,0 ... Não consigo me acostumar a isso.
E a última frase eu não entendo de todo. Quais valores a 0?
Vejo que a resposta correta é minEquity ==0,0 ... Não consigo me acostumar a isso.
E a última frase eu não entendo de todo. Quais valores a 0?
Mas não sei se uma conversão de tipo implícito pode causar um erro. Referia-me à comparação de tipos reais. Isto é, aqui, para ser seguro, eu escreveria desta maneira:
Entretanto, não sei se a conversão implícita do tipo pode causar um erro, eu estava falando, em princípio, em comparar tipos reais. Isto é, aqui, por confiabilidade, eu o escreveria assim:
Alexey Viktorov: Sim, minha versão conta dinheiro com duas casas decimais. Isto não é uma citação, portanto não se pode ser tão preciso a respeito.
Não é uma questão de meticulosidade, é uma questão de precisão. No seu caso, isso poderia resultar em um valor zero sendo escrito no buffer. Se você não quer tal precisão, faça-o desta maneira:
Não é uma questão de meticulosidade, é uma questão de precisão. No seu caso, isso poderia resultar em um valor zero sendo escrito no buffer. Se você não quer essa precisão, faça-o desta maneira:
Por que eu sou tão estúpido? Como eu poderia não ter adivinhado que é melhor inicializar a minEquidade com um valor diferente de zero? Então tudo será mais fácil...
Por que eu sou tão estúpido? Como eu poderia não ter adivinhado que é melhor inicializar a minEquidade com um valor diferente de zero? Então tudo seria mais fácil...
Esse não é realmente o problema. Embora de alguma forma tenha sido contornada, o lixo no buffer do indicador quando o indicador começa não está correto.
Não tem. Haverá uma quebra de conexão de várias barras, várias barras serão desinicializadas com lixo.
Ou, como Dmitry disse acima, houve uma quebra de conexão de várias barras. A propósito, será que o retorno pré-calculado será 0 também em caso de falha de conexão?
Aparentemente, houve de fato uma quebra na comunicação neste momento.
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
E é mais provável que, quando há uma pausa, os retornos pré_calculados 0.
OK, foi uma longa pausa, mas o que causou os outros nulos pré_calculados?
A partir destas linhas.
2016.10.18 23:51:20.865 Network '4092672': scanning network for access points
Até aqueles acima não há outros registros além dos registros comerciais como este.
E você pode ver quantas zeragens de pré-cálculos foram feitas em meu posto anterior.
Potencialmente, a falha pode estar aqui:
{
minEquity = 0;
maxEquity = 0;
}
minEquity = NormalizeDouble(fmin((minEquity == 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Quando uma nova barra chega, você repõe os valores para 0 - multa. Mas então você verifica minEquidade e 0 para igualdade, o que não é recomendado.
Para provar minhas palavras, aqui está a sua imagem. Você pode ver que os valores do "lixo", como você disse, são cerca de zero.
É claro, é melhor acrescentar uma janela de dados na imagem com o valor "lixo".Você pode explicar por que este método não é recomendado?
Esta (minEquity == 0? bal : minEquity) parte do código, se minEquity == 0, retornará o valor do bal que foi obtido anteriormente; o valor do minEquity não mudará até que a função fmin() termine.
Embora eu concorde que tal escrita é um pouco arriscada. mas esse não é o problema.
Você pode explicar com mais detalhes por que este método não é recomendado?
esta (minEquity == 0? bal : minEquity) parte do código, se minEquity == 0, retornará o valor do bal obtido anteriormente; o valor do minEquity não mudará até que a função fmin() termine
Embora eu concorde que esta forma de escrever o código é um pouco arriscada. mas esse não é o problema.
Eu estava falando especificamente sobre isto: minEquity ==0. Você está comparando sobre a igualdade dos números do duble. Isso pode explicar a queda nos valores para 0.
Vejo que a resposta correta é minEquity ==0,0 ... Não consigo me acostumar a isso.
E a última frase eu não entendo de todo. Quais valores a 0?
Vejo que a resposta correta é minEquity ==0,0 ... Não consigo me acostumar a isso.
E a última frase eu não entendo de todo. Quais valores a 0?
Mas não sei se uma conversão de tipo implícito pode causar um erro. Referia-me à comparação de tipos reais. Isto é, aqui, para ser seguro, eu escreveria desta maneira:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Entretanto, não sei se a conversão implícita do tipo pode causar um erro, eu estava falando, em princípio, em comparar tipos reais. Isto é, aqui, por confiabilidade, eu o escreveria assim:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Sim, minha versão conta dinheiro com duas casas decimais. Isto não é uma citação, portanto não se pode ser tão preciso a respeito.
Não é uma questão de meticulosidade, é uma questão de precisão. No seu caso, isso poderia resultar em um valor zero sendo escrito no buffer. Se você não quer tal precisão, faça-o desta maneira:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Então não haverá erro.
Não é uma questão de meticulosidade, é uma questão de precisão. No seu caso, isso poderia resultar em um valor zero sendo escrito no buffer. Se você não quer essa precisão, faça-o desta maneira:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Nesse caso, não haverá erro.
Por que eu sou tão estúpido? Como eu poderia não ter adivinhado que é melhor inicializar a minEquidade com um valor diferente de zero? Então tudo será mais fácil...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Você também pode usar maxEquity = DBL_MIN;
Por que eu sou tão estúpido? Como eu poderia não ter adivinhado que é melhor inicializar a minEquidade com um valor diferente de zero? Então tudo seria mais fácil...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Bem... Ou assim...