Quaisquer perguntas de recém-chegados sobre MQL4 e MQL5, ajuda e discussão sobre algoritmos e códigos - página 1477

 
MakarFX:

Ainda assim, ele verifica cada carrapato

e o cálculo mínimo é feito... enrola duas barras para trás.

Meu cálculo mínimo estava sendo atingido como em sua foto. Mas depois acrescentei a variável LoY1 e ela parou este erro. Como resultado, todos os pedidos são abertos da mesma maneira (por tempo, quantidade e preço) que no meu código inicial, ou seja, da maneira que eu preciso deles. Meu código falhou em outro lugar .... Mas eu o consertei no mesmo lugar.


double LoU,LoY1,Pr;
int x;
void OnTick()
{
if (Low[1]>Low[2]&&Time[2]>x&&Low[2]<LoY1)
{
LoU=Low[2];
LoY1=Low[2];
}
//**************************************************************
if (Bid-LoU>=0.0030&&Pr!=LoU)
{
OrderSend(Symbol(),OP_SELL,0.1,Bid, 3,0,0,"300",0);
Pr=LoU;
LoU=Bid;
LoY1=Bid;
x=TimeCurrent();
}
}

E você também pode colocar ordem pendente em 30 pontos do LoU ao invés de abrir no mercado. E então você não precisa verificar Bid em cada tick. Mas no caso de uma ordem pendente, toda vez que o LoU muda , devemos apagar a antiga ordem pendente e definir uma nova, ou alterar os parâmetros de uma ordem pendente atual sem apagá-la. E tudo isso deve ser feito com muito menos freqüência do que verificar cada lance de licitação .

Qual variante no meu caso é a que consome menos tempo em termos de implementação do código?

1. Verifique a cada tick se a Licitação está a 30 pontos do LoU

2. A cada mudança de LoU, apague o antigo pendente e defina um novo.

3. A cada mudança de LoU, altere os parâmetros da pausa ativa

Obrigado por sua ajuda
.

 
ANDREY:

O meu cálculo do mínimo estava disparando como na sua foto. Mas depois acrescentei a variável LoY1 e ela a parou.

Existem funções padrão iLowest eiHighest.

 
ANDREY:

O meu cálculo do mínimo estava disparando como na sua foto. Mas depois acrescentei uma variável LoY1 e parou este desvio. Como resultado, todos os pedidos abrem da mesma maneira (por tempo, quantidade e preço) que no meu código original (isto é, da maneira que eu quero). Meu código falhou em outro lugar .... Mas eu o consertei no mesmo lugar.


E você também pode colocar ordem pendente em 30 pontos do LoU ao invés de abrir no mercado. E então você não precisa verificar Bid em cada tick. Mas no caso de uma ordem pendente, toda vez que o LoU muda , devemos apagar a antiga ordem pendente e definir uma nova, ou alterar os parâmetros de uma ordem pendente atual sem apagá-la. E tudo isso deve ser feito com muito menos freqüência do que verificar cada lance de licitação .

Qual variante no meu caso é a que consome menos tempo em termos de implementação do código?

1. Verifique a cada tick se a Licitação está a 30 pontos do LoU

2. A cada mudança de LoU, apague o antigo pendente e defina um novo.

3. A cada mudança de LoU, os parâmetros de mudança da posição ativa

1) x não é int, é a data (será útil no futuro)

2) seu código inicial não tem ordens pendentes

3) Agora seu código faz mais operações em cada tick

Verifique sua mensagem

 
Taras Slobodyanik:

existem funções padrão iLowest eiHighest.

Não adequado... o número de itens de série temporal não é constante
 
MakarFX:
Não... o número de elementos de série temporal não é constante

er... isso impede que você encontre o alto/baixo?

 
Taras Slobodyanik:

er... isso impede que você encontre alto/baixo?

As funçõesiLowest eiHighest significam pesquisar entre um certo número de barras (número de elementos de série temporal)

neste caso, o número é desconhecido e muda a cada vez

 
MakarFX:

1) x não é int, é data e hora (será útil no futuro)

2) seu código inicial não tem ordens pendentes

3) agora seu código faz mais operações em cada tick

Verifique sua mensagem.

Este é meu antigo código

Este é meu novo código para o mesmo período de tempo que o antigo

O número de operações por tick é muito menos importante para mim do que o tempo gasto com este número. E o novo código leva 25% menos tempo.... se não estou enganado.

Obrigado pela ajuda.

 
Aleksei Stepanenko:
Há aqui uma sutileza. Primeiro definimos o tamanho e depois, ao zerarmos, liberamos a fixação, isto não muda o tamanho. Não há outra forma de contornar isto.
Muito obrigado!
 
MakarFX:

Ainda assim, ele verifica cada carrapato

e o cálculo da baixa sai... retrocede duas barras.

Abaixo está meu código original sem seus acréscimos

Abaixo com suas últimas melhorias



Talvez se (TimeSeconds(TimeCurrent())==0) devesse ser aplicado somente àquelas seções onde não há pedidos abertos, e onde o próximo mínimo é procurado?

Se não estou enganado graças à sua função, meu código começou a ser executado apenas no início de cada vela de minuto, por isso ele abre as ordens não corretamente.


Obrigado pela ajuda.

 
ANDREY:

Abaixo está meu código original sem seus acréscimos

Abaixo está o código com suas últimas melhorias



Talvez, se(TimeSeconds(TimeCurrent())==0) deve ser aplicado somente àquelas seções onde nenhum pedido é aberto, e onde o próximo mínimo é procurado?

Se não estou enganado, sua função começou a executar meu código apenas no início de cada vela de minuto.


Obrigado pela ajuda.

Sim
Razão: