Em uma aplicação do OOP - página 2
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
O principal é como utilizá-lo depois. Para tentar diferentes entradas, você pode fazer isso a granel pelo número do conjunto de entradas. Ou seja, há uma coleção de conjuntos de entradas. Se for conveniente, então como um conjunto de funções. As mais simples - compra ou venda incondicional por mercado. Ou condicional))). E então executaremos o otimizador e procuraremos através dos diferentes conjuntos de entradas.
Sim, até agora parece que definimos o número da estratégia em configurações e otimizamos por número no otimizador. Mas esta é a primeira vez, há muito tempo que eu sonho em fazer uma auto-otimização na mosca.
Qual é a finalidade desta auto-optimização (função alvo)?
O objetivo é óbvio. Em primeiro lugar, o otimista no testador está faltando no dia atual, pelo menos no MT4 com certeza. E eu faço isso para o MT4.
Em segundo lugar, o mercado pode mudar drasticamente durante o dia, sem nenhuma razão (notícia). Provavelmente você já notou, um apartamento preguiçoso... E de repente, como se a mostarda tivesse sido espalhada sob a cauda, as citações começam a rasgar. Ou é um apartamento, ou é o caos total.
Penso que podemos classificar tais condições e incluir a modificação necessária da estratégia ao defini-las. Como fazer isso? Eu não tenho coragem suficiente para criar uma IA. Mas o método de otimização pode determinar indiretamente o estado.
Até agora, estes são apenas pensamentos não testados.
Sim, parece que até agora, definimos o número de estratégias em cenários e otimizamos por números no otimizador. Mas esta é a primeira vez, por muito tempo eu tenho um sonho de fazer uma auto-otimização em tempo real.
Seu cliente quer embrulhar todas as estratégias que conhece em um único especialista, como eu o entendo. Você não poderá concluir esta tarefa até que tenha uma lista de estratégias. Sugiro a elaboração conjunta dos ToR.
Se MAIS a esta lista de estratégias você tocar na questão da auto-optimização, então escreva-lhe uma rede neural, não reinvente a roda e não confunda a mente de seu cliente com o conhecimento da programação básica. Isto é exatamente o que ele pede a você.
E posso lhes dar um exemplo de "batida"?
Aqui está. Hierarquia das classes comerciais na biblioteca padrão:
Isso implica que o módulo de gerenciamento de dinheiro é um Expert Advisor. O Trailing Stop também é um Expert Advisor. O Expert Advisor inclui outros Expert Advisors. Esta herança inconsistente resulta do fato de que tanto o trailing stop quanto o gerenciamento de dinheiro precisam ter acesso a alguns dados privados e métodos de um Consultor Especialista básico.
A propósito, existem longas grinaldas de herança. Os CIndicators usam CIndicatorBuffer que, por sua vez, chama seus métodos superiores. Como resultado, um simples rastreamento do valor do indicador torna-se uma tarefa muito confusa. Após três chamadas recorrentes, perdemos completamente a noção de onde algo está vindo.
E este é apenas um exemplo de má herança. De fato, qualquer hierarquia de classes mais ou menos grande baseada na herança quase sempre se torna inconsistente, confusa e recursiva. O que torna extremamente difícil a depuração e o desenvolvimento posterior.
Pensamos que a profundidade da herança deve ser limitada a 1-2 níveis. Além disso, o primeiro nível deve herdar da definição global e universal do CObjeto de nível zero (todos são objetos) e implementar a entidade específica "Expert", "Indicator", "Trailing Stop". O segundo nível deve implementar a implementação específica do "Expert Advisor based on MACD", "indicador SMA", "Trailing Stop", etc. Mas o uso do terceiro nível deve ser severamente punido e processado.
Em outras palavras, acontece que a classificação é uma ferramenta verdadeiramente valiosa somente quando o é:
Seu cliente quer embrulhar todas as estratégias que conhece em um único especialista, como eu o entendo. Você não poderá concluir esta tarefa até que tenha uma lista de estratégias. Sugiro a elaboração conjunta dos ToR.
Se MAIS a esta lista de estratégias você tocar na questão da auto-optimização, então escreva-lhe uma rede neural, não reinvente a roda e não confunda a mente de seu cliente com o conhecimento da programação básica. Isto é exatamente o que ele pede a você.
Aqui está. Hierarquia das classes comerciais na biblioteca padrão:
Isso implica que o módulo de gerenciamento de dinheiro é um Expert Advisor. O Trailing Stop também é um Expert Advisor. O Expert Advisor inclui outros Expert Advisors. Esta herança inconsistente resulta do fato de que tanto o trailing stop quanto o gerenciamento de dinheiro precisam ter acesso a alguns dados privados e métodos de um Consultor Especialista básico.
A propósito, existem longas grinaldas de herança. Os CIndicators usam CIndicatorBuffer que, por sua vez, chama seus métodos superiores. Como resultado, um simples rastreamento do valor do indicador torna-se uma tarefa muito confusa. Após três chamadas recorrentes, perdemos completamente a noção de onde algo está vindo.
E este é apenas um exemplo de má herança. De fato, qualquer hierarquia de classes mais ou menos grande baseada na herança quase sempre se torna inconsistente, confusa e recursiva. O que torna extremamente difícil a depuração e o desenvolvimento posterior.
Pensamos que a profundidade da herança deve ser limitada a 1-2 níveis. Além disso, o primeiro nível deve herdar da definição global e universal do CObjeto de nível zero (todos são objetos) e implementar a entidade específica "Expert", "Indicator", "Trailing Stop". O segundo nível deve implementar a implementação específica do "Expert Advisor based on MACD", "indicador SMA", "Trailing Stop", etc. Mas o uso do terceiro nível deve ser severamente punido e processado.
Agora eu entendo a idéia. A propósito, a maneira simples como eu implementei isto em meus robôs comerciais, como eu salientei. Apenas os nomes são diferentes.
ZS: Em que você fez tal gráfico? Algo a la Doxygen?
Aqui está. Hierarquia das classes comerciais na biblioteca padrão:
Isso implica que o módulo de gerenciamento de dinheiro é um Expert Advisor. O Trailing Stop também é um Expert Advisor. O Expert Advisor inclui outros Expert Advisors. Esta herança inconsistente resulta do fato de que tanto o trailing stop quanto o gerenciamento de dinheiro precisam ter acesso a alguns dados privados e métodos de um Consultor Especialista básico.
A propósito, existem longas grinaldas de herança. Os CIndicators usam CIndicatorBuffer que, por sua vez, chama seus métodos superiores. Como resultado, um simples rastreamento do valor do indicador torna-se uma tarefa muito confusa. Após três chamadas recorrentes, perdemos completamente a noção de onde algo está vindo.
E este é apenas um exemplo de má herança. De fato, qualquer hierarquia de classes mais ou menos grande baseada em herança quase sempre se torna inconsistente, confusa e recursiva. O que torna extremamente difícil a depuração e o desenvolvimento posterior.
Pensamos que a profundidade da herança deve ser limitada a 1-2 níveis. Além disso, o primeiro nível deve herdar da definição global e universal do CObjeto de nível zero (todos são objetos) e implementar a entidade específica "Expert", "Indicator", "Trailing Stop". O segundo nível deve implementar a implementação específica do "Expert Advisor based on MACD", "indicador SMA", "Trailing Stop", etc. Mas o uso do terceiro nível deve ser severamente punido e processado.
Em outras palavras, acontece que a classificação é uma ferramenta verdadeiramente valiosa somente quando o é:
+ pensamentos muito verdadeiros.
ZS: Em que foi elaborado um gráfico desse tipo? Algo a la Doxygen?
Sim, se ao menos ;) Acordei sobre isto em SnagIt por cerca de uma hora. Fi-lo especialmente para o meu artigo.