75.000 opções - 4GB de RAM e 4GB de cache de disco não são suficientes???? - página 6

 
Mak:
Renat escreveu (a):

Mas por que há apenas 1000 excessos em um espaço tão grande? É muito difícil. Eu executei este Expert Advisor em MT4 sobre uma área de 1,5 bilhões de valores e ele resultou em 4400 rebotes líquidos em 4 minutos sobre um histórico de 18000 barras EURUSD H1. ....
E em genética, a velocidade de busca é independente do tamanho do espaço de parâmetros.
Depende da qualidade da função alvo (adequação).
E que função alvo você usou?
  • max NetProfit
  • max NetProfit e min DD
  • max NetProfit e max PF
  • algo mais?
Eu não vi tal função de alvo em seu código. Eis o que temos como parâmetros otimizadores:



Além disso, usamos o algoritmo original, que é uma ordem de grandeza mais rápida do que outros algoritmos que conhecemos.
1000 corridas é um pouco demais, normalmente uso 100-200 corridas (para qualquer número de parâmetros) para avaliar uma solução.

Duvido muito de cerca de 100-200 corridas. Qual é a população utilizada? 16? :) Quando você começa com uma grande área de busca, você pode facilmente obter 256 excessos na primeira geração de 256 habitantes na estimativa inicial. Esta é a variante mais suja. É isto o que você quer dizer (administrar a primeira população e parar)? Você acredita em resultados de 100-200 corridas em um enorme campo de variantes? Quem precisa de resultados tão sujos?

Eis o que obtive quando executei a Amostra MACD em 198, construída sobre suas condições iniciais a partir da primeira página desta linha:





De uma área de busca de 35 bilhões de amostras em excesso, foram feitas 12800 corridas em 8 minutos e 46 segundos em um histórico de 18691 barras no modo "por preço de abertura". O melhor relatório de caso está anexado.
 
Infelizmente, seus relatórios não são tão simples e indicativos como no MetaTrader. Você postou o arquivo XLS do relatório da Omega com o número 880, embora não haja descrições dos parâmetros encontrados nesta passagem 880 em nenhum lugar (nem no próprio relatório XLS, nem no relatório TSGO, nem nas capturas de tela deste tópico).





Além disso, há muitas perguntas sobre os dados inconsistentes (todos de seus relatórios no arquivo ZIP). Os lucros, número de negócios, etc. não chegam nem perto dos dados do relatório TSGO (o arquivo XLS é feito para a execução do 880, como indicado na última página do relatório).



Além disso, por que TakeProfit está a 80 pips e o trailing stop a 6700?

Qual é a explicação para tudo isso? Parece que seu teste é tão deficiente que não pode ser levado em conta de forma alguma.

As provas/explicações devem ser simples e fáceis de entender, não confundindo ao ponto de ter que fazer perguntas como esta. Uma captura de tela que não mostra nada e um arquivo com dados inconsistentes é prova para aqueles que são preguiçosos demais para descobri-lo.
 
Não, Renat, tudo está correto e no lugar.
Pode não estar claro na hora ...

Deixe-me explicar os resultados.

1. O critério de otimização pode ser arbitrário.
(sobre a função alvo)
É calculado pelo próprio usuário e passado para a TSGO.
Ou seja, você pode usar tanto aqueles que você tem como quaisquer outros que um usuário possa sonhar.
Por exemplo, você pode usar os pagamentos esperados como critério.
(ou seja, probabilidade de acordos com pagamento positivo esperado, ou em outras palavras, o sistema funciona no lado positivo)
. Ou, alguns critérios descrevendo linearidade de equidade (ajuda a resolver problemas similares ao Walk Forward Optimization) ...
O critério de otimização tem um papel fundamental na otimização.
(para obter o resultado certo, não o CurveFitting)

2. A otimização pode ser feita simultaneamente de acordo com muitos critérios.
(sobre a função alvo)
Eu só tenho um protótipo da próxima versão do TSGO em casa.
Você pode definir vários critérios de otimização simultaneamente (ver a função TS.GO.Criterion(...)).
No exemplo da tabela do telespectador, os critérios utilizados são destacados com fundo amarelo - são NetProfit, MaxDD, ProfitFactor.
Isto é, a TSGO buscou sistemas em torno do máximo destes três critérios (MaxDD em Omega é com um sinal de menos).
Isto é, buscou sistemas com grande lucro, com grande fator de lucro e mínimo DrawDown.
Resultados interessantes podem ser obtidos simultaneamente maximizando o NetProfit para cada ano (ou mês),
ou seja, procurando sistemas com bons resultados para cada ano ou mesmo mês sobre o histórico.
(no TSGO os critérios de otimização podem ser estabelecidos até 1000, na realidade eu tentei até agora cerca de 150-200 - isto é NetProfit por meses no MSFT)

3. Nosso tamanho populacional é de até 1000 exemplares (poderíamos fazer mais, mas parece ser demais).
(Duvido muito que 100-200 corridas. Então, que tipo de população é utilizada? 16? :))
Nesse exemplo em particular, acho que foi 100 (ver o valor do parâmetro em TS.GO.Popul(...))
Costumo usar uma população de 50-100 habitantes, às vezes 1000.
Em geral, isto tem pouco efeito, você sempre pode definir para 1000, quase não tem efeito sobre a velocidade da busca.
Os resultados são muito precisos, mesmo com 500 corridas com uma população de 1000 ... :))
Eu lhe disse que estou usando meu próprio algoritmo original, que até agora na Internet não vi nada sobre isso.
É muito mais rápido do que todos os outros algoritmos que conheço (e provavelmente usado por você).
O tamanho da população nela não importa (desde que não seja muito pequena) ...

É isto o que você quer dizer (gerir a primeira população e parar)?
Isso é o que você diz, para mim funciona de maneira diferente.

Você acredita em resultados de 100-200 execuções em um enorme campo de variantes?
E mais, tenho certeza de que os resultados da CS são independentes do número de variantes no espaço de parâmetros.

Quem precisa de resultados tão sujos?
Eles não são desarrumados, são razoavelmente suficientes.
Nunca é garantido que você obtenha resultados precisos em CS.
A única maneira de obter um resultado exato é fazer um completo overshoot.
Ou seja, você sempre tem uma estimativa - um resultado aproximado.
Meu algoritmo pode obter uma boa estimativa na maioria dos casos já em 100-200 execuções.

De uma área de busca de 35 bilhões de buscas, 12800 execuções foram feitas
Em meu algoritmo 2000 execuções foram mais do que suficientes.

Infelizmente, seus relatórios não são tão simples e indicativos como o MetaTrader. Você postou o arquivo de relatório XLS da Omega com o número 880, embora não exista uma descrição dos parâmetros encontrados desta execução 880 em nenhum lugar (nem no próprio relatório XLS, nem no relatório TSGO, nem nas capturas de tela deste tópico).
O que fazer ...
Se a Omega Research comprou nosso TSGO e o incorporou em seu pacote, então seria apenas uma caixa de seleção como a sua.
Mas por enquanto é apenas um suplemento à TradeStation.

Tudo está correto com os resultados.
Run 880 é o melhor segundo a Omega (pelo critério NetProfit),
mas não o melhor segundo a TSGO (simultaneamente pelos critérios NetProfit, MaxDD, ProfitFactor)

A TSGO usa Omega apenas para organização de loop by pass.
Além disso, você pode selecionar qualquer critério disponível na Omega, e isso não afeta o trabalho da TSGO.
A TSGO faz a otimização com base nos critérios especificados pelo usuário no código do sinal.
O número da corrida obtida em Omega também não desempenha nenhum papel.
Quando a otimização é concluída, os resultados são dados, por exemplo, a partir da primeira linha do telespectador.

Além disso, há muitas perguntas sobre os dados inconsistentes (tudo isso é de seus relatórios no arquivo ZIP). Os lucros, número de negócios, etc. não chegam nem perto dos dados do relatório TSGO (o arquivo XLS é feito para a execução 880, que é indicado na última página do relatório).
Sim, pode-se ter essa sensação, você fez um excelente trabalho analisando meu exemplo ... :))
Um pouco de esclarecimento é necessário aqui.

A questão é que a TSGO usa uma característica da Omega para relatar o melhor sistema encontrado.
O melhor sistema é a primeira linha do espectador, substitua seus parâmetros e você verá uma correspondência completa dos resultados com o relatório.

A Omega busca o sistema de acordo com seus critérios (não nos interessa qual),
A TSGO busca o sistema de acordo com seus critérios, definidos no sinal pelo usuário.

Durante o processo de otimização, Omega muda o parâmetro Gen de 1 para K (este é o parâmetro de otimização definido em Omega).
O valor do Gen é enviado à TSGO.

Se o Gen aumenta, então o TSGO emite parâmetros do novo candidato para testar os resultados da corrida.
Se a Gen não aumentou, então a TSGO considera que a otimização acabou (Omega recalcula o melhor resultado em sua opinião),
neste caso a TSGO emite os parâmetros da melhor instância encontrada (da primeira linha do telespectador).

Em geral, quando a otimização é concluída, o relatório Omega mostra os resultados da instância a partir da primeira linha do telespectador.
Compare seus parâmetros e eles são exatamente os mesmos.

Tudo isso porque o TSGO é um suplemento ao Omega e não faz parte dele.
Não há outra maneira de fazer isso.
============================================================================

Renat, eu lhe asseguro que estes são dados absolutamente reais, e que tudo neles está absolutamente correto.
A confusão surge porque não somos os desenvolvedores da Omega e não podemos construir o otimizador dentro da Omega.
 

Você acredita nos resultados de 100-200 corridas em um enorme campo de variantes?
Além disso, tenho certeza de que os resultados da CS não dependem do número de variantes no espaço de parâmetros.

Não seja um crente. Teria a gentileza de provar seu ponto de vista sobre esta recontagem?



Tudo está correto com os resultados.
Run 880 é o melhor de acordo com a Omega (de acordo com o critério NetProfit),
mas não o melhor de acordo com o TSGO (pelos critérios NetProfit, MaxDD, ProfitFactor simultaneamente)

Portanto:
  • Você não listou os melhores parâmetros de execução encontrados 880
  • Você nos diz que "preto é branco", justificando-o com as peculiaridades de seu addon
  • Você enviou um relatório Omega intencionalmente incorreto
  • Você não indicou exatamente qual função alvo você usou para obter os resultados de 1000 execuções, e em vez disso entrou no modo "você pode fazer isto ou aquilo" (o programador pode definir o critério no próprio código - mostre este critério em seu código EL)
Não _confirme_ a mim. Melhor _provar_ em números e relatórios. Você nos forçou a passar para o campo da solução de problemas no nível de "cavalos em um vácuo esférico" (obrigado por isso), nós nos movemos e resolvemos o problema. Mas você não o resolveu de forma alguma, e até nos enganou com relatórios errados.

Tudo o que você citou anteriormente como evidência desde o início deste tópico é um completo disparate com jogos de palavras. Não há provas, apenas um jogo de números estranhos. Você teria a gentileza de tomar o IBM Daily de 1970 a 1999 (exatamente do início de 1970 ao início de 1999) e executar os limites acima (exatamente seus) e publicar tal relatório de modo que não haja nenhuma reivindicação a ele. E eu vou publicar o meu.
 
Renat, por que você sempre se mete no meu caso?
E por que eu sempre tenho que dar desculpas aqui?
Se você quiser que eu saia do fórum, por favor.
Basta me proibir aqui também, e eu farei mais trabalho e menos distrações.

Se você não entende algo, isso não significa que você foi enganado.
Isso só significa que você não entende, e na sociedade educada.
as pessoas apenas pedem explicações para coisas que não entendem.

As pessoas geralmente julgam os outros por si mesmas.
Eu, por exemplo, nunca questionei uma única vez a honestidade dos participantes do fórum.
(Ao contrário de você...).

Responderei em ordem.

1. Em um dos meus posts escrevi:
Além disso, usamos o algoritmo original, que é uma ordem de grandeza mais rápida do que outros algoritmos que conhecemos.
1000 corridas é um pouco demais, para estimar uma solução que normalmente uso 100-200 corridas (para qualquer número de parâmetros).

Você me respondeu:

Você mesmo acredita nos resultados de 100-200 corridas em um enorme campo de variantes?
Além disso, tenho certeza absoluta de que os resultados da CS não dependem do número de variantes no espaço de parâmetros.

Não tenha fé. Teria a gentileza de provar suas palavras neste recálculo?
---
O que eu tenho que provar para você?
Que "eu normalmente uso 100-200 execuções (para qualquer número de parâmetros)" ?
E eu considero tais resultados suficientemente confiáveis?

Essa é minha opinião, e por que eu deveria prová-la?
Você não acha que sim? - Esse é o seu direito.
Você pode simplesmente dizer: "Acho que não".
Haverá duas opiniões sobre o mesmo assunto.

2. Você não forneceu uma lista dos melhores parâmetros encontrados para a série 880
A série 880 não é a melhor em termos de TSGO,
e pode não estar mais na população.
A melhor tiragem é 919, que é mostrada na primeira linha do visualizador TSGO.
É o que você vê no relatório Omega.

Compare.

No telespectador, linha 1.
Gen = 919 (este é o número da corrida)
Oportunidades = 52
NetProfit = 29312.07
MaxDD = -4939.19
PF = 7,42

No relatório Omega
Lucro líquido total = $29.312,07
Total # de negócios = 52
Máximo de drawdown intraday = ($4.939,19)
Fator de lucro = 7,42

Por que a Omega fez a corrida número 880, escrevi em uma mensagem anterior.

3. Você me enviou um relatório falso da Omega.
Enviei um relatório deliberadamente falso Omega, veja com mais cuidado.

4. Você não especificou exatamente qual função alvo você usou para obter os resultados de 1000 execuções
Já o escrevi em meu posto anterior, a otimização foi realizada simultaneamente usando três critérios - NetProfit, MaxDD, ProfitFactor. Eles são destacados no visor com fundo amarelo.

No código do sinal em Easy eles são definidos pela função TS.GO.Criterion

Aqui está um trecho de código:
R = TS.GO.Method(1); -- permitindo a otimização multicritério.
R = TS.GO.Critério("NetProfit",1); -- primeiro critério
R = TS.GO.Critério("MaxDD",1); -- segundo critério
R = TS.GO.Critério("PF",1); -- terceiro critério

Os valores dos critérios são atribuídos no final do código na última barra:
R = TS.GO.Set("NetProfit",NetProfit);
R = TS.GO.Set("MaxDDD",MaxIDDrawDown);
R = TS.GO.Set("PF",GrossProfit/(0,001-GrossLoss));

Não tenho nenhum desejo de ouvir seus ataques.
Se quisermos conversar, precisamos estar em pé de igualdade.
Você concorda?

Então, por favor, tente provar suas afirmações.

1. Você enviou um relatório obviamente falso para a Omega.
2. Você não indicou exatamente qual função alvo você usou para obter seus resultados.
3. E você mesmo não o resolveu de forma alguma, e também o enganou com relatórios incorretos.
4. Tudo o que você deu anteriormente como evidência desde o início deste tópico é um completo disparate com jogo de palavras. (Isto não é apenas uma afirmação - já é um insulto)
5. Não há provas, apenas um jogo de números estranhos.
 
Como você mesmo pode ver, você tem que explicar em vários postos porque um é o outro e o outro ainda é o outro. Isto é especialmente interessante quando se trata de relatórios e provas. Como costumo perguntar - simples e direto. Precisamos de relatórios computadorizados que venham com o máximo de uma linha de comentários do autor.

Continuo sugerindo que passemos do reino dos jogos de palavras apenas para o reino dos relatórios práticos. Da última vez eu sugeri que o problema fosse resolvido novamente. Você pode resolver isso e publicar relatórios que são inquestionáveis?

Após esta tarefa, podemos avançar sem problemas para uma declaração sobre a suficiência de 100-200 execuções em enormes campos de variantes.
 
Eu lhe dei os relatórios do computador.
Houve apenas um mal-entendido com o número Omega run.
No próximo post eu lhe expliquei em detalhes do que se trata.

Sobre a suficiência de 100-200 execuções em enormes campos de variantes.

Eu não fiz uma declaração ou afirmação.
Eu escrevi literalmente o seguinte:
... Normalmente uso 100-200 execuções (para qualquer número de parâmetros) para estimar uma solução

Você entende a diferença entre "estimativa" e "suficiência"?

Isto é especialmente interessante quando se trata de relatórios e provas, como eu costumo pedir - simples e simples. Você precisa de relatórios computadorizados que venham com o máximo de uma linha de comentários do autor cada um.
Teria prazer em explicar em duas palavras, mas se você não entende isso, tenho que escrever mensagens com quilômetros de comprimento ...

Depois desta missão...
E você me contratou para me dar tarefas?

Continuo esperando por você para provar suas CONCLUSÕES.
 
Fornecer um relatório limpo, nós o verificaremos novamente e eu pedirei desculpas onde eu estava errado. Os relatórios são uma bagunça, e os parâmetros encontrados parecem muito pouco com as melhores opções. Vamos analisar o relatório limpo e depois avaliar a exatidão do otimizador genético (seu e nosso).

Se você estiver fazendo reclamações técnicas ultrajantes, tenha a gentileza de prová-las.
Já lidamos com 100-200 corridas e os resultados acabaram sendo absolutamente sujos (embora "estimados") (eu disse isso imediatamente, mas você não concordou). E você tinha que admitir isso apenas sob pressão.
 
Se você estiver fazendo afirmações técnicas estranhas, seja gentil o suficiente para prová-las.

Eu não faço reivindicações técnicas estranhas.
Para ser mais preciso - para você, eles podem estar fora dos limites, mas para mim são bastante comuns, funcionando.

Já lidamos com 100-200 corridas e acontece que estes resultados são absolutamente sujos (embora "estimados") (eu disse isso imediatamente, mas você não concordou). E isto você só tinha que admitir sob pressão.

Eles não são "absolutamente sujos", mas resultados bastante viáveis.
E eu não concordei com nada sob nenhuma pressão.
Eu sempre disse a mesma coisa, posso dizê-lo novamente.


Especialmente para você,
Eu fiz outra otimização em Omega.
Deixei apenas um critério de otimização - NetProfit- para facilitar a sua vida.
O mesmo critério foi utilizado em Omega.
No total, foram 1000 corridas.

IBM, 7800 barras, até 1999/12/31
(Omega não tem data de início de período, tem data de fim e número de barras)

Teste em barras diárias por Barra fechada (por Open Omega não faz)
Paradas, dedos dos pés e rastreamento em código feito por pedidos pendentes,
como Omega dentro de barra não funciona de outra forma e os dados só têm barras diárias.

No anexo:
@Renat.txt - código de sinal EL, difere do anterior, na medida em que resta apenas um critério.
1000.XLS - Relatório do sistema Omega (melhor execução segundo Omega)
SOR.xls - Relatório de teste Omega (todas as execuções)
TSGO-1000.CSV - composição da última população no TSGO (tamanho da população 100).

A definição do bloco de critérios foi alterada no código do sinal:

R = TS.GO.Method(1);
R = TS.GO.Criterion("NetProfit",1); -- segundo parâmetro = 1 - busca do critério máximo
R = TS.GO.Criterion("MaxDD",0); -- segundo parâmetro = 0 - otimização por critério é desativada
R = TS.GO.Criterion("PF",0).GO.Criterion("PF",0); -- segundo parâmetro = 0 - a otimização por critério está desativada

Favor notar

1.
A primeira linha no visor corresponde à primeira linha da população e corresponde aos resultados em Omega.
2. O número da melhor corrida no telespectador é 401, no Omega 948, se você olhar em SOR.xls você verá que estas corridas têm os mesmos resultados. A TSGO rejeita repetidos resultados correspondentes.
3. se você olhar a composição da última população, você verá que o melhor resultado encontrado tem NetProfit 1891,86 (em 401 corridas), o resultado de 213 corridas é 1814,16, o resultado de 93 corridas é 1796,40. Ou seja, o resultado para a 93ª corrida foi diferente do melhor resultado após 1000 corridas em 5,3%, o que eu acho que não é ruim e pode ser considerado como uma boa estimativa do NetProfit.


Abaixo está uma captura de tela

Arquivos anexados:
1000.zip  35 kb
 
Obrigado, vou tentar checar tudo novamente esta noite e responder.
Razão: