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
Sugiro que aqueles que desejam discutir os geradores e suas estratégias "passem". aqui.
Desculpas ao autor SX por não utilizar a filial para o fim a que se destina.
E mais sucesso!
Muito obrigado e muito obrigado.
Na segunda-feira tentarei fazer uma versão na qual mudarei a ordem de otimização, para que não haja uma parada inicial.
>> E aqui está ele.
Lá está ela.
Desculpe, corrigiu o erro de desligamento ao abrir um pedido. Adicionada verificação de saldo para abertura mínima. Por favor, todos que baixaram a versão anterior, atualizem para a nova versão.
gostaria de ouvir algumas críticas e sugestões construtivas (de qualquer tipo).
Eu gostaria de ter algum tipo de certeza. :)
Tipo, eu quero certeza. :)
E onde você sugere que a mudemos? Sou a favor de mudar o comentário.
__________________________
Comecei a trabalhar às 4 horas.
O progresso se parece com isto:
Meu computador não é o mais potente.
Assim, o relógio em um computador normal pode funcionar de forma realista mesmo em 24 horas. E se você a dividir...
Esta diminuição do tempo restante se deve ao fato de que a maior concentração de estratégias significativas está agora no início, antes disso, estava no meio.
Eu sou a favor de mudar o comentário.
Eu concordo.
O principal é que o "original" de todos deve ter uma "referência". Caso contrário, como você trocará os conjuntos :).
Assim, o relógio em um computador normal pode realisticamente mesmo em um dia. E se o analisarem...
E se os "preços de abertura", então ... Eu já "encaixei" 10 vezes, e todas as variantes falham no OOS.
(O encaixe do relógio EURUSD é todo de 2008. 3 iterações - Condição_X -> Secundário_ -> Condição_X)
Os resultados dos modelos "Todos os carrapatos" e "por preços de abertura" coincidem
Eu concordo.
O principal é que todos devem ter um "conjunto de referência". Caso contrário, como você trocará os conjuntos :)
Além dos set's, você pode trocar arquivos e apenas condicionar as cordas. Uma correção estará na próxima versão.
E se "preços de abertura", então ... Eu já "encaixei" 10 vezes e todas as variantes estão drenando no OOS.
Claro que a preços de abertura ohh. Por que atormentar o computador por nada?
(encaixe das armações de relógios EURUSD - tudo de 2008. 3 iterações - Condição_X -> Secundário_ -> Condição_X)
Tenho feito testes desde 99.
gostaria de ouvir algumas críticas e sugestões construtivas (de qualquer tipo).
- IMHO. É melhor retirar o bloco "// Externs" e o bloco "// aqui" em um "inludnik" separado, para que ninguém tenha sequer uma mão para editar o arquivo base.
- E em "codificação", IMHO, é melhor passar de números "BuyCondition9()" para alguns "mnemônicos", para que ninguém acrescente simultaneamente "BuyCondition786()" completamente diferentes. Caso contrário, o "repositório" terá que ser mantido pelo autor. Como capitalizar funções à esquerda e funções à direita - "BB_O" (para Condition9) ou adicionar "apelido de autor" ao prefixo. Mas então você terá que "maquiar" funções "bool BuyCondition(int index)" e "bool SellCondition(int index)".
Em alguns de meus projetos, em parâmetros externos (e ini-files os duplico) há muito tempo venho escrevendo algo como "+EURUSD" - "compre EURUSD". Será um pequeno passo para o intérprete. :)
'
ZS.
Mas é difícil otimizá-lo. :)
'
ZY.
Se ao menos pudéssemos encontrar um compromisso entre "externo otimizado" (int) e a impossibilidade para o usuário final de utilizar números/funções reservados... Este produto superaria todos os outros em flexibilidade e versatilidade. Embora "para minha amada" seria uma complicação desnecessária. :)
Uma correção estará na próxima versão.
E os pedidos de Comentários em cadeia externa!!!!!
'
- IMHO. É melhor colocar o bloco "// Externs" e o bloco "// aqui" em um "inluder" separado, para que ninguém tenha sequer uma mão para editar o arquivo base.
Na verdade, eu ia fazer isso.
Na versão 1.0, a divisão planejada em módulos, limpeza, co-geração (provavelmente), e alguma mana para escrever.
Para que se pareça mais ou menos com um produto.
- E em "codificação", IMHO, é melhor fugir dos números "BuyCondition9()" para alguma "mnemônica" para que ninguém acrescente "BuyCondition786()" completamente diferente ao mesmo tempo. Caso contrário, o "repositório" terá que ser mantido pelo autor. Como capitalizar funções à esquerda e funções à direita - "BB_O" (para Condition9) ou adicionar "apelido de autor" ao prefixo. Mas neste caso você terá que "maquiar" funções "bool BuyCondition(int index)" e "bool SellCondition(int index)".
É aí que eu sou contra. Embora a adição de condições seja facilitada, ela não é bem-vinda. Digamos apenas que uma vez que você muda o código, não pode contar com apoio.
Se você precisar acrescentar uma condição, me diga, eu a acrescentarei.
Se apenas para encontrar um compromisso entre "externo otimizado" (int) e a impossibilidade para o usuário final de usar números/funções reservados... A flexibilidade e a versatilidade deste produto superaria todos os outros. Embora "para minha amada" seria uma complicação desnecessária. :)
Por que se preocupar em procurá-lo? É chamado de Foolproofing, em inglês simples. Normalmente, é a proteção da integridade dos dados em qualquer etapa da execução.
Por enquanto, isto só existe parcialmente, e a adição na versão 1.0 ainda não está prevista.
Se você não puder usar o terminal, você pode sempre verificar a integridade à mão.
E os pedidos de Comentários em cadeia externa!!!!!'.
Eu não entendo isso aqui.