Erros, bugs, perguntas - página 433

 

Renat, se puder, por favor, prestar atenção à candidatura #124661 no SR.

Tenho estado à espera de uma resposta desde 13 de Junho.

 
voix_kas:

Renat, se puder, por favor, prestar atenção à candidatura #124661 no SR.

Tenho estado à espera de uma resposta desde 13 de Junho.

Por isso, foi-lhe dada a resposta certa mais do que uma vez. Respondi-lhe novamente.

 
Renat:

Por isso, foi-lhe dada a resposta certa mais do que uma vez. Respondeu-lhe novamente.

Não vejo a resposta nesta candidatura. O último comentário é meu de 2011.06.21 09:25 (um lembrete repetido da relevância da pergunta).

Duplicando-o aqui só por precaução:

Compreendo correctamente que o limite do volume/quantidade mínima de um comércio/ordem só é relevante para a abertura de uma posição?
Aplicam-se a negócios/ordens que resultam no encerramento, aumento, diminuição ou inversão de posições?
O limite mínimo do acordo aplica-se a todos os cinco (5) dos cenários acima referidos.
Parece que todos os cenários possíveis estão descritos. Ou existem outros cenários para além destes cinco (5)?

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок - Документация по MQL5
 

Já lhe responderam duas vezes, depois eu respondi.

Responderei novamente - sim, os encerramentos completos não são abrangidos pela regra do limite de volume.

 
papaklass:
Estamos a falar de aumentar a velocidade da MQL5?
Sim, a optimização do código significa exactamente isso.
 
Renat:

Foi-lhe respondido duas vezes, depois eu respondi.
Vou responder novamente - sim, os encerramentos completos não estão sujeitos à regra do limite de volume.

Renat, não me interpretes mal. Repito a minha pergunta não para mimar, mas para a esclarecer.
Até agora a sua resposta e a dos seus colegas (no SD) abrange 2 (dois) cenários: 1) abrir uma posição e 2) concluir o encerramento de uma posição (provavelmente com ORDER_FILLING_AON a ser obrigatório).
A execução de uma ordem (comércio) poderesultar em pelo menos três (3) mais cenários: aumentar, diminuir ou inverter uma posição.
Infelizmente, não encontro qualquer explicação clara destes três cenários nas respostas da MQ. :(

Para maior clareza, aqui estão alguns exemplos(em todos os casos no servidor, lote mínimo = 1,0; passo mínimo = 0,1):

Exemplo #1 (encurtamento de posição).
Temos uma posição longa de 1,0. Estamos a tentar fechar completamente a posição (usando ORDER_FILLING_CANCEL). Enviamos uma ordem de venda de lote 1.0. A ordem é parcialmente executada (0,9 lotes).
O resultado é que existe uma posição longa aberta de 0,1 lote. Assim, podemos concluir que o requisito de volume mínimo do lote não se aplica ao cenário de encurtamento de posição.

Exemplo 2 (inversão de posição).
Temos uma posição longa de 0,1 lote. Envio uma ordem de venda ao servidor para o volume de 0,2 lotes. O servidor irá aceitar esta encomenda? (Os requisitos do lote mínimo não são novamente cumpridos).

Exemplo 3 (aumento de posição).
Temos uma posição longa de 0,1 lote. Envio ao servidor uma ordem de compra de 0,1 lote.

 
voix_kas:


Para ilustrar, aqui estão alguns exemplos(em todos os casos o lote mínimo = 1,0; passo mínimo = 0,1):

Exemplo 1 (posição curta).
Temos uma posição longa de 1,0 lotes. Estamos a tentar fechar completamente a posição (usando ORDER_FILLING_CANCEL). Enviamos uma ordem de venda no volume de 1.0 lote. A ordem é parcialmente executada (0,9 lotes).
O resultado é que existe uma posição longa aberta de 0,1 lote. Assim, podemos concluir que o requisito de volume mínimo do lote não se aplica ao cenário de encurtamento de posição.

Se a posição fechar parcialmente a 0,9 (com uma ordem a 1,0), então teremos de enviar outra ordem para fechar o saldo a 0,1.

E se a ordem for executada através de um portal externo, há uma grande probabilidade de que só fechariam todo o volume de lote 1.0 de uma só vez, não nos permitindo dividi-lo.

Exemplo 2 (inversão de posição).

Temos uma posição longa de 0,1 lote. Envio uma ordem de venda ao servidor para o volume de 0,2 lotes. O servidor aceita esta encomenda? (Os requisitos do lote mínimo não são novamente cumpridos).

Não se trata de uma operação de liquidação totalmente zero, pelo que o pedido será rejeitado.


Exemplo 3 (aumento do volume da posição).
Tenho uma posição longa de 0,1 lote. Envio uma ordem de compra ao servidor para o volume de 0,1 lote. O servidor exemplo de uma tal ordem?

Claro que não.

Por favor, leia as regras literalmente e não tente inventar as suas próprias condições. A regra é simples "a regra do limite de volume pode não se aplicar quando uma posição é liquidada em ZERO". Esta regra tem sido expressa muitas vezes.


Deve também ter em conta que qualquer corretor ou qualquer porta de troca pode utilizar as suas próprias regras de controlo de volume, mais rigorosas.

 
Estou a ver. Obrigado pelo esclarecimento.
 
IlyaBukalov:

O número máximo de linhas entre as quais os parênteses de abertura/fecho serão realçados é de 128. Esta limitação foi introduzida porque não faz sentido destacar parênteses de abertura e fecho que não cabem num só ecrã. Além disso, o desempenho do MetaEditor aumentou consideravelmente após esta restrição ter sido introduzida.

É muito inconveniente quando um parêntese não é realçado após 128 cordas, é muitas vezes necessário percorrer dois ou três ecrãs para encontrar onde o parêntese está fechado.
 
voix_kas:

Não é uma questão crucial, mas mesmo assim. Concatenação de cordas. A documentação descreve duas funções StringAdd e StringConcatenate.

...

Resultado:

2011.06.26 19:10:55 teste (EURUSD,H1)№1 2012 milissegundos, i = 10000000
2011.06.26 19:11:04 teste (EURUSD,H1)#2 8269 milissegundos, i = 10000000
2011.06.26 19:11:10 teste (EURUSD,H1)#3 6661 milissegundos, i = 10000000

Acontece, no entanto, que a adição normal é mais rápida.

Este exemplo é incorrecto.

O primeiro método deve ter "resultado = resultado + corda1 + corda2 + corda3;"

Também faria resultados diferentes para todos os 3 testes, caso contrário não começarão em condições iguais (alguma memória já está atribuída).

Melhor ainda - colocar testes em diferentes roteiros e executá-los sequencialmente.


Tenho-o assim:

1. comprimento = 10`000

2011.06.27 02:43:07 sStingTest (EURUSD,M1) №1 2542 milisegundos, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #2 0 milissegundos, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #3 0 milissegundos, i = 10000


2. comprimento = 100`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #2 47 milisegundos, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 15 milisegundos, i = 1000000

Acabamento #1 - não esperou


3. comprimento = 1`000`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #2 780 milisegundos, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 187 milisegundos, i = 1000000

O fim do nº 1 não teve lugar.


4. comprimento = 10`000`000

2011.06.27 02:48:14 sStingTest (EURUSD,M1) #3 1903 milissegundos, i = 10000000

MemoryException: 602492946 bytes não disponíveis" erro iniciado no segundo teste.


Conclusão: StringConcatenate é o mais rápido.


A propósito, a função StringAdd também não tem um exemplo de comparação muito correcto.

O meu código para o testar está em reboque.

Arquivos anexados: