Perguntas de Iniciantes MQL5 MT5 MetaTrader 5 - página 486
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Pergunta - o testador leva em conta a troca?
Calculado em Excel (conta em cêntimos) e obteve um resultado estranho
P.P. Tipo de dados Preço do lote MaxHigh MaxEqDrd
1 2014.06.12 09:52 venda 0,1 1,6824 0,16824 1,7179 -3,55
2 2014.06.12 15:18 venda 0,2 1,6831 0,33662 1,7179 -6,96
3 2014.06.12 17:52 venda 0,3 1,6836 0,50508 1,7179 -10,29
4 2014.06.12 19:10 venda 0,5 1,6839 0,84195 1,7179 -17,00
5 2014.06.12 23:00 venda 0,8 1,6845 1,3476 1,7179 -26,72
6 2014.06.16 09:59 venda 1,3 1,6985 2,20805 1,7179 -25,22
7 2014.06.19 09:58 vender 2.1 1.7017 3.57357 1.7179 -34.02
8 2014.06.19 11:21 vender 3.4 1.7018 5.78612 1.7179 -54.74
9 2014.06.19 20:40 venda 5,5 1,7033 9,36815 1,7179 -80,30
10 2014.06.19 22:12 venda 8,9 1,7036 15,16204 1,7179 -127.27
11 2014.06.20 05:10 venda 14.4 1.7047 24.54768 1.7179 -190.08
12 2014.06.20 05:22 venda 23,3 1,7049 39,72417 1,7179 -302,90
13 2014.06.26 12:38 venda 37,7 1,7030 64,2031 1,7179 -561,73
14 2014.06.26 15:18 venda 61,0 1,7033 103,9013 1,7179 -890,60
15 2014.06.27 06:51 venda 98,7 1,7050 168,2835 1,7179 -1273.23
16 2014.06.30 17:37 venda 100.0 1.7079 170.79 1.7179 -1000.00
17 2014.06.06.30 17:37 venda 59,7 1,7079 101,96163 1,7179 -597,00
18 2014.07.01 09:03 venda 100,0 1,7100 171 1,7179 -790,00
19 2014.07.01 09:03 vender 100.0 1,7100 171 1,7179 -790.00
20 2014.07.01 09:03 vender 58.4 1,7100 99,864 1,7179 -461.36
21 2014.07.01 11:30 venda 100.0 1,7110 171.1 1,7179 -690.00
22 2014.07.01 11:30 venda 100.0 1,7110 171.1 1,7179 -690.00
23 2014.07.01 11:30 venda 100,0 1,7110 171,1 1,7179 -690,00
24 2014.07.01 11:30 venda 100,0 1,7110 171,1 1,7179 -690,00
25 2014.07.01 11:30 venda 18.1 1 1.7110 30.9691 1.7179 -124.89
26 2014.07.02 02:33 vender 100,0 1,7145 171,45 1,7179 -340,00
27 2014.07.02 02 02:33 vender 100,0 1,7145 171,45 1,7179 -340,00
28 2014.07.02 02:33 vender 100,0 1,7145 171,45 1,7179 -340,00
29 2014.07.02 02:33 vender 100,0 1,7145 171,45 1,7179 -340,00
30 2014.07.02.02:33 vender 100.0 1.7145 171.45 1.7179 -340.00
31 2014.07.02 02:33 vender 100,0 1,7145 171,45 1,7179 -340,00
32 2014.07.02 02:33 vender 76,5 1,7145 131,15925 1,7179 -260,10
33 2014.07.02.02 11:32 venda 100.0 1.7176 171.76 1.7179 -30.00
34 2014.07.02 11:32 venda 100.0 1.7176 171.76 1.7179 -30.00
35 2014.07.02 11:32 venda 100.0 1,7176 171.76 1,7179 -30.00
36 2014.07.02 11:32 vender 100,0 1,7176 171,76 1,7179 -30,00
37 2014.07.02 11:32 vender 100,0 1,7176 171,76 1,7179 -30,00
38 2014.07.02 11:32 venda 100.0 1,7176 171.76 1,7179 -30.00
39 2014.07.02 11:32 venda 100.0 1,7176 171.76 1,7179 -30.00
40 2014.07.0202 11:32 venda 100.0 1,7176 171.76 1,7179 -30.00
41 2014.07.02 11:32 venda 100.0 1,7176 171.76 1,7179 -30.00
42 2014.07.0202 11:32 vender 100,0 1,7176 171,76 1,7179 -30,00
43 2014.07.02 11:32 venda 94,6 1,7176 162,48496 1,7179 -28,38
Total:2865.5 4909.88611 -12756.34
Preço médio de abertura -> 1.7134
Alto 04.07.2014 1.7179
Sorteio em pips -> 0.0045
Sorteio em moeda ->12756,34
Sorteio segundo o código -> 13823,00
Sorteio segundo o relatório do testador ->23669,03
TP - > 1.7084
Lucro em pips -> 0.0050
Lucro segundo o cálculo - > 14465.91
Lucro segundo o relatório - > 13915.05
Como é que o sorteio não se soma - especialmente ao relatório do provador? Antes não existiam posições fechadas!
É assim que a situação no gráfico se apresenta
-Aleks-:
A variável global é relevante quando se trabalha realmente no mercado - preciso de informação de teste - é por isso que não me preocupei com ela.
Não estava a falar de GlobalVariable, estava a falar do nível das variáveis globais.
-Aleks-:
O que é equidade e equilíbrio - é claro que sei, mas ainda não sei como é calculado o drawdown. Os meus exemplos de código mostram que tentei tomar tanto o equilíbrio como os fundos como máximos e, do mesmo modo, tomei o equilíbrio e os fundos como mínimos.
Não dominei a fórmula de cálculo do levantamento no testador, mas pode tentar calcular a diferença entre o seu saldo antes da abertura da ordem e o capital mínimo antes do fecho da ordem. Ou, calcular os fundos mínimo e máximo e a diferença máxima será o saque máximo.
-Aleks-:
Porque pensa que a desigualdadese (BalansNew<BalansMax) ProfitNew=BalansNew-BalansMax; nunca se mantém? Só não é cumprido na barra quando o novo saldo máximo é atingido (ou equidade - ainda não é verdade), mas nesse momento eu fixo o levantamento de lucrosProfitMin=ProfitNew.Isto é mais relevante uma vez que o saque máximo não é normalmente atingido no momento do encerramento da encomenda, e o objectivo é calcular o montante médio necessário para o trabalho da EA.
Concordo, não estive suficientemente atento.
Mas o saque não é por dia mas por ordem(s) de vida e depois disso a equidade torna-se um equilíbrio. Estes são exactamente os lugares no gráfico de teste onde as linhas de equidade e equilíbrio se encontram num ponto.
Eu não estava a falar de GlobalVariable, estava a falar de nível variável global.
Aparentemente compreendi-o mal - as minhas variáveis são inicializadas antes da execução do código bloquear no início(), por isso não deve haver problemas com o mashing ou algo do género... Ou há outra razão?
Não entrei na fórmula de cálculo do drawdown no testador, mas podemos tentar calcular a diferença entre o saldo antes da abertura da ordem e o capital próprio mínimo antes do fecho da ordem. Ou, pode tentar contar a diferença entre os fundos máximo e mínimo e a diferença máxima será o saque máximo.
E se houver muitas encomendas, devemos contar para cada encomenda e escolher a maior? No meu exemplo, podemos ver que o drawdown calculado foi duas vezes menos em comparação com o resultado do testador e de acordo com o seu algoritmo será ainda menos.
A frequência de redacção do ficheiro é um assunto puramente pessoal, mas o levantamento não é contado para o dia, mas para a vida da(s) ordem(s), e depois os fundos tornam-se um saldo. Estes são exactamente aqueles lugares no gráfico do testador onde as linhas de equidade e equilíbrio se encontram num ponto.
Não importa quando o testador tem em conta o saque - o facto é que será máximo num determinado dia e o resultado deve coincidir, e não coincide - e isso é surpreendente.
Preciso do levantamento diário para testar a carteira de negociação - para compreender quantos fundos podem ser necessários de uma só vez e com que frequência.
Matematicamente (o levantamento de fundos revelou-se 23497,1 contra 23669,03 do testador), o levantamento de fundos está próximo do tamanho do segmento que simboliza a mudança no depósito - ou seja, a diferença entre o valor máximo do Capital Próprio e o valor mínimo do Capital Próprio.
Devo tê-lo entendido mal - as minhas variáveis são inicializadas antes do bloco de execução do código no início(), por isso não deve haver problemas com o mashing ou algo assim... Ou há outra razão?
E, se houver muitas encomendas, devemos calcular para cada encomenda e seleccionar a maior? No meu exemplo pode ver que o drawdown calculado é quase metade do do testador e, de acordo com o seu algoritmo, será ainda menos.
Não importa quando o testador leva em conta o saque - o facto é que será máximo num determinado dia e o resultado deve coincidir, e não coincide - e isso é surpreendente.
Preciso do levantamento diário para testar a carteira de negociação - para compreender quantos fundos podem ser necessários de uma só vez e com que frequência.
Não exactamente. Não para cada encomenda, mas desde a abertura da primeira encomenda até ao encerramento da última. Isto é, de OrderTotal() == 0 a OrderTotal() == 0.
Este é o ponto desde a abertura da primeira ordem até ao encerramento da última; devemos determinar o sorteio, uma vez que o lançamento real terá lugar a qualquer momento, e, consequentemente, o sorteio pode acontecer durante períodos de 24 horas.
Tudo o resto... Não gosto de olhar para a investigação de outras pessoas, bem como em código longo, posso discutir formas de resolver alguns problemas, mas não exemplos de código. Mas é estranho que ninguém tenha corrigido as minhas suposições sobre como é calculado o levantamento de crédito.
De qualquer modo, não gosto do seu método de cálculo do levantamento de crédito. Parece-me que imprime com tanta frequência, que é preciso muita paciência para o descobrir.
Karputov Vladimir:
Desculpe incomodá-lo, enquanto limpava o programa para encontrar o problema da paragem do testador, no texto do programa encontrei uma violação do seu algoritmo. A compilação estava a correr bem, mas o testador parou sem indicar o ponto de falhaНе кусок, а программу, которую можно скомпилировать и прогнать в режиме отладки.
Não exactamente. Não para cada encomenda, mas desde a abertura da primeira encomenda até ao fecho da última. Isto é, de OrderTotal() == 0 a OrderTotal() == 0.
Este é o ponto desde o momento da abertura da primeira ordem até ao encerramento da última; devemos determinar o sorteio, uma vez que o lançamento real terá lugar a qualquer momento, não às 0:00, pelo que o sorteio pode acontecer durante um período de 24 horas.
Assim, neste exemplo, estas condições são exactamente observadas - as encomendas são abertas e monitorizadas para fechar a cada sinal.
Se de facto o cálculo vai do máximo para o mínimo de equidade, então este showdown vai ajudar-me a repensar as leituras do testador...
De qualquer modo, não gostei do seu método de cálculo do levantamento de crédito. Parece-me que imprime tão frequentemente que é preciso ter muita paciência para o descobrir.
O que me interessa é quanto dinheiro a EA realmente precisa - ou seja, o levantamento real (perda actual) desde a abertura da encomenda até ao seu encerramento menos qualquer lucro perdido.
Imprime uma vez por dia - isso não é frequente, e é necessário para certos fins.
À primeira vista, a tarefa parece tão simples como três cêntimos. MAS! ....
Há uma linha de qualquer oscilador na janela indicadora, que se agita em relação a "0" com amplitude diferente.
O verdadeiro problema é:
- Na passagem "0" de baixo para cima, desenhar uma seta na borda inferior da janela indicadora,
- Na passagem "0" de cima para baixo, para desenhar uma seta perto da borda superior da janela indicadora,
- à auto-escala do gráfico oscilador na janela indicadora, as setas devem permanecer automaticamente nos seus limites da janela indicadora.
Isto é, percorrendo o gráfico para trás e para a frente através do histórico, ou alterando a sua escala horizontal, as setas devem permanecer sempre nos limites da janela indicadora automaticamente.
Por favor, não dêem nenhum conselho, "ajudem-me com dinheiro"))). Preciso de um exemplo de um código de trabalho, que implemente esta função, ou de uma ligação a um.
Obrigado de antemão!