Não deve ser logicamente igual a zero - não está claro por que isso é o caso!
Seu d1 dá números minúsculos, eu evito tais problemas convertendo preço em int, ou seja, por exemplo int bid=int((tick_array[0].bid+_Point/10)/_Point); com certeza, às vezes você recebe 0,00000999999 em 5 dígitos, se você fizer cálculos em dobro
Não deve ser igual a zero pela lógica - não entendo porque acontece dessa maneira!
Funciona em debugger no Si-9.18. O tempo em taxas é 2016 por alguma razão. Embora o valor de i seja 2189. Assim, ele inicia o cálculo no início do gráfico, onde não há liquidez. O tempo inicial entre o início e a parada é de 1 hora. Mas para essa hora, há apenas um valor de tempo. Ele o encontra tanto com a variável de partida quanto com a variável de parada. Como resultado, partida = parada. É claro, se você subtrai-las, você recebe zero. Eu ainda não descobri o resto.
ovak77: Você tem d1 com números minúsculos, eu evito tais problemas de conversão de preço para int, ou seja, por exemplo int bid=int((tick_array[0].bid+_Point/10)/_Point); com certeza, às vezes ele retorna 0 se os cálculos forem feitos em dobro
Não vamos discutir d1 - se for necessário, então é necessário, tudo é contado corretamente lá. A questão é: por que temos o mesmo valor para start_time e stop_time, assim como start_index e stop_index?
Não vamos discutir d1 - se for necessário, então é necessário, tudo é contado corretamente lá. A questão é: por que temos o mesmo valor para start_time e stop_time que para start_index e stop_index ?
Cabe a você, tente dividir 0,0000099999 por 2, por exemplo
Primeiro você temlimit=start_index-stop_index+1, ou seja,limit===1, e depois onde a divisão por 2 élimit=(int)(stop_time-start_time)/PeriodSeconds(_Period). Um não é adicionado. Zero é dividido pelo período.
Funciona em debugger no Si-9.18. O tempo em taxas é 2016 por alguma razão. Embora o valor de i seja 2189. Assim, começa o cálculo no início do gráfico onde não há liquidez. O tempo inicial entre o início e a parada é de 1 hora. Mas para essa hora, há apenas um valor de tempo. Ele o encontra tanto com a variável de partida quanto com a variável de parada. Como resultado, partida = parada. É claro, se você subtrai-las, você recebe zero. Eu ainda não descobri o resto.
Sim, desta forma, não ocorrem erros. Mas se você entrar em algum instrumento ilíquido ou tempo ilíquido - sessão noturna, por exemplo, então você pode facilmente conseguir 1 barra baixa dentro de uma hora. Assim, o limite = 0 é garantido para você! E se a cotação for 2 - então o limite/2 ainda dará 0 quando arredondado.
Sim, isso não é um erro. Mas se você entrar em algum instrumento ilíquido ou tempo ilíquido - por exemplo, durante a sessão noturna, pode haver 1 barra baixa em uma hora. Assim, o limite = 0 é garantido para você! E se a cotação for 2 - então o limite/2 ainda será 0 quando arredondado.
Talvez, vou pensar sobre isso, obrigado. Mas o problema global é algo mais.... O problema é que ela não é estável.
Não deve ser logicamente igual a zero - não está claro por que isso é o caso!
Não deve ser igual a zero pela lógica - não entendo porque acontece dessa maneira!
Funciona em debugger no Si-9.18. O tempo em taxas é 2016 por alguma razão. Embora o valor de i seja 2189. Assim, ele inicia o cálculo no início do gráfico, onde não há liquidez. O tempo inicial entre o início e a parada é de 1 hora. Mas para essa hora, há apenas um valor de tempo. Ele o encontra tanto com a variável de partida quanto com a variável de parada. Como resultado, partida = parada. É claro, se você subtrai-las, você recebe zero. Eu ainda não descobri o resto.
Você tem d1 com números minúsculos, eu evito tais problemas de conversão de preço para int, ou seja, por exemplo int bid=int((tick_array[0].bid+_Point/10)/_Point); com certeza, às vezes ele retorna 0 se os cálculos forem feitos em dobro
Não vamos discutir d1 - se for necessário, então é necessário, tudo é contado corretamente lá. A questão é: por que temos o mesmo valor para start_time e stop_time, assim como start_index e stop_index?
Não vamos discutir d1 - se for necessário, então é necessário, tudo é contado corretamente lá. A questão é: por que temos o mesmo valor para start_time e stop_time que para start_index e stop_index ?
Depois de outro desligamento, o terminal deixa de funcionar.... Como posso ressuscitá-lo sem reinstalá-lo?
Acabou ficando pendurado na memória - matou à força o processo - ele começou.
Como é possível que o tempo se torne igual? Tudo tem funcionado corretamente há meio ano...
Funciona em debugger no Si-9.18. O tempo em taxas é 2016 por alguma razão. Embora o valor de i seja 2189. Assim, começa o cálculo no início do gráfico onde não há liquidez. O tempo inicial entre o início e a parada é de 1 hora. Mas para essa hora, há apenas um valor de tempo. Ele o encontra tanto com a variável de partida quanto com a variável de parada. Como resultado, partida = parada. É claro, se você subtrai-las, você recebe zero. Eu ainda não descobri o resto.
Coloque BarsUsed=100 nos parâmetros de entrada.
Coloque BarsUsed=100 nos parâmetros de entrada.
Sim, desta forma, não ocorrem erros. Mas se você entrar em algum instrumento ilíquido ou tempo ilíquido - sessão noturna, por exemplo, então você pode facilmente conseguir 1 barra baixa dentro de uma hora. Assim, o limite = 0 é garantido para você! E se a cotação for 2 - então o limite/2 ainda dará 0 quando arredondado.
Sim, isso não é um erro. Mas se você entrar em algum instrumento ilíquido ou tempo ilíquido - por exemplo, durante a sessão noturna, pode haver 1 barra baixa em uma hora. Assim, o limite = 0 é garantido para você! E se a cotação for 2 - então o limite/2 ainda será 0 quando arredondado.
Talvez, vou pensar sobre isso, obrigado. Mas o problema global é algo mais.... O problema é que ela não é estável.
Cabe a você, tente dividir 0,0000099999 por 2, por exemplo
Impresso d1 - para os meus propósitos é
De qualquer forma, não é essa a questão, obrigado.