Bibliotecas: MT4Orders QuickReport - página 6
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
As informações sobre o drawdown máximo longo são interessantes. Eu a criei para toda a matriz de strings. Ainda não atualizei o código no site.
Mas não está muito claro para que serve a data. Se fizermos uma divisão em testes back/forward (como sugeri), precisaremos calcular as estatísticas sobre eles separadamente em duas tabelas (os períodos máximos de drawdown também estarão lá).
Fiz um cálculo completo das estatísticas para os testes back/forward
O arquivo foi atualizado..
O que não está muito claro com a data é para que ela serve.
Se você quiser assistir a partir de 2020, será bem-vindo. De 2023, sem problemas. É que, às vezes, você não se importa com o que foi em 2010. E isso mostra que a duração mais longa foi em 2010.
A definição de uma data futura ajudaria a separar as estatísticas.
Ah - entendi o ponto. Não para um testador com um especialista/estratégia, mas para uma conta real em que diferentes ideias foram testadas.
Eu mesmo o usaria somente para um testador. Os drawdowns reais não são nada interessantes.
O que há de errado com isso?
Estilo potencialmente perigoso. Por exemplo, algum tempo depois, você vai querer escrever sua própria função de formatação de data personalizada e a chamada dela será escrita em uma linha superlonga por hábito:
Mas não há garantia de que Format-ids será chamado depois de MaxLengthDD, só porque eles estão listados à direita entre os somatórios.
Em princípio, um registro superlongo de uma linha tem lados negativos: é difícil de ler e entender (na verdade, é difícil repetir em sua mente a análise de uma expressão como um compilador faz, mas um ser humano não é um compilador, afinal), é difícil de depurar. E um registro tão compacto também não proporciona nenhum ganho de desempenho.
Super biblioteca! Obrigado ao autor!
Sugestões de melhorias:
- ocultar o gráfico interativo (ou adicionar outro mecanismo para isso) ao clicar no gráfico novamente,
- salvar o código-fonte em UTF-8, para que ele possa ser lido normalmente pelo GitHub (esse é um evento único, que não ameaçará nada, mas acrescentará conveniência)
- verificar se há caracteres proibidos no nome do arquivo (\ / / : * ? ? " < > | : :) e substituí-los por algo neutro (-, por exemplo)
- adicionar um parâmetro para salvar relatórios na pasta comum dos terminais, para que você não precise procurá-los nas pastas dos agentes.
Mais uma vez obrigado, a ferramenta é muito útil!
Mais uma vez, obrigado, ferramenta muito útil!
Adicionei 2 novos parâmetros à chamada
common_path - salvar na pasta comum do terminal. Para evitar que os arquivos sejam sobrescritos por outro agente durante a otimização, adicionei o número do agente (3000, 3001,...) aos nomes dos arquivos. Ao salvar na pasta do testador (falso), eles são salvos na pasta do agente que executou os cálculos.
fileANSI - salvar em codificação ANSI ou em UNICODE. O tamanho dos arquivos UNICODE é duas vezes maior e leva mais tempo para ser processado, portanto, se você carregar muitos dados, por exemplo, 1 GB, é mais econômico usar ANSI. O UNICODE é adicionado para compatibilidade com serviços de terceiros, se você precisar dele.
O verificador de caracteres e o botão ocultar também foram adicionados, mas não os descrevi.
Adicionados 2 novos parâmetros à chamada
É assim que novos parâmetros serão adicionados. É por isso que é melhor escrever a assinatura uma vez, onde a estrutura das condições é inserida. Assim, a assinatura não será alterada. Foi isso que fiz no Report.
Provavelmente melhor. Mas já é necessário manter o esquema de chamadas atual, para compatibilidade com programas prontos que usam a biblioteca, para que ninguém precise editar o código.
A sobrecarga ajudará.