Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 2623
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
e a resposta não era destinada a si - ainda não sabe ler...
Não precisa sequer de um segundo modelo aqui, pois não? - Validação Cruzada e Pesquisa Grid para Selecção de Modelos ...
mas talvez apenas a matriz de confusão responda à sua 2ª pergunta (o objectivo do 2º modelo da sua ideia)...
.. . ou
... Só duvido que precise do 2º modelo ... imho
Aqui é apenas reivindicada a melhoria da matriz de confusão com o segundo modelo, se ler o Prado, por exemplo. Mas também utiliza exemplos de sobreamostragem do primeiro modelo para aumentar o número de "verdadeiros positivos" ou outra coisa qualquer. Já me esqueci, infelizmente.
Amostragem para cima e para baixo são para conjuntos de dados desequilibrados e pequenos conjuntos de formação - se é isso que quer dizer - ou seja, dar pesos mais elevados a classes mais pequenas e vice-versa... Sim, provavelmente para os aumentar (verdadeiros positivos)...
***
e cerca de 2 modelos - bem, é provavelmente possível filtrar 2 vezes - primeiro sinais para fixar os pesos, e depois negocia-los de acordo com esses pesos (lançados por entradas na 2ª pesagem)... embora pareça ser possível aprender sobre negócios com contexto - e manter o gradiente para séries temporais anteriores - boa ideia... MAS a implementação quando se trabalha com contexto ainda é geralmente um pouco diferente - a tarefa é usar a codificação "transacção e o seu contexto" e o 2º RNN toma em processamento o resultado do 1º para descodificar na saída -- mas tem pouco a ver com o trabalho de 2 redes em 2 tarefas diferentes (por exemplo, contexto e transacções), uma vez que, de facto, é processado - passado através de 2 redes "transacção e contexto" (como um par!!!!)... - apenas resolve a questão da velocidade , mas não (ou em menor medida) a validade da produção... imho...
mas se quer realmente separar o processamento de contexto e transacção (contexto separadamente, transacções separadamente) -- até agora tal construção lembra-me uma sanduíche (ou óleo e manteiga, lubrificando inter-relações e dependências de fenómenos um do outro - em 2 camadas)... Não pretendo interpretar a vossa TechSuite, mas expressei as minhas preocupações e sugestões de que ainda pode valer a pena preservar no processo de modelização - nomeadamente as Relações! Desejo-vos uma bela (reflexo da realidade! não de óleo amanteigado) Arquitectura de Rede!
p.s. ) como um eterno problema de "publicidade contextual" - "o principal é não se afastar da realidade" (apenas a sua configuração de escala é por vezes torta - não vou apontar dedos para quem - ou com pequenas amostras trabalhadas na direcção errada)
Amostragem para cima e para baixo são para conjuntos de dados desequilibrados e pequenos conjuntos de treino - se é isso que quer dizer - ou seja, dar mais peso a classes mais pequenas... Sim, provavelmente para os aumentar (verdadeiros positivos)...
***
e cerca de 2 modelos - bem, é provavelmente possível filtrar 2 vezes - primeiro sinais para fixar os pesos, depois trocas sobre eles de acordo com esses pesos (lançadas por entrada na 2ª pesagem)... embora pareça possibilidade de aprender trocas com contexto - e manter o gradiente para séries temporais anteriores - boa ideia... MAS a implementação quando se trabalha com contexto ainda é geralmente um pouco diferente - a tarefa é usar a codificação "transacção e o seu contexto" e o 2º RNN toma em processamento o resultado do 1º para descodificar na saída -- mas tem pouco a ver com o trabalho de 2 redes em 2 tarefas diferentes (por exemplo, contexto e transacções), uma vez que, de facto, é processado - passado através de 2 redes "transacção e contexto" (como um par!!!!)... - apenas resolve a questão da velocidade , mas não (ou em menor medida) a validade da produção... imho...
mas se quer realmente separar o processamento de contexto e transacção (contexto separadamente, transacções separadamente) -- até agora tal construção lembra-me uma sanduíche (ou óleo e manteiga, lubrificando inter-relações e dependências de fenómenos um do outro - em 2 camadas)... Não pretendo interpretar a vossa TechSuite, mas expressei as minhas preocupações e sugestões de que ainda pode valer a pena preservar no processo de modelização - nomeadamente as Relações! Desejo-vos uma bela (reflexo da realidade! não de óleo amanteigado) Arquitectura de Rede!
p.s. ) como um eterno problema de "publicidade contextual" - "o principal é não fugir da realidade" (apenas a sua configuração de escala é por vezes torta - não apontarei dedos a quem - ou com pequenas amostras trabalhadas na direcção errada)
O conceito de regularidade implica repetibilidade, isso é importante!
as estatísticas são lineares, qualquer que seja a sua forma de ver. as redes neurais são burras (ou inteligentes - depende do desenvolvedor) ponderação... usar 2 ou mais camadas de Dense ns para ponderação dá dependências não lineares (convencionalmente falando, porque a dependência é OU a correlação burra ainda é uma questão muito grande)... mas desde que até uma correlação idiota funcione - pode tentar ganhar dinheiro com isso... - o momento em que deixa de funcionar deve ser detectado a tempo (é necessário notar algum tipo de anomalia - aleatória ou sistemática - essa é outra questão - e depois, como de costume, decidir sobre a sua questão de risco/rentabilidade)
a conveniência ns está na sua flexibilidade - pode obter/fornecer uma "nomenclatura" bastante diferente da produção. É flexível - pode obter/fornecer uma "nomenclatura" bastante diferente da entrada - ou seja, pode fazer as transformações de que precisamos na própria rede... e fá-lo em modo multi-tarefa (depende da biblioteca)... e não apenas estatísticas...
Se precisa ou não de estatísticas para encontrar um input é outra questão...
conhecimento e experiência ajudam mais frequentemente do que o processamento estatístico - porque o primeiro centra-se em especificidades, o segundo na redução a um denominador comum ...
Tudo tem o seu lugar - também as estatísticas...
***
a questão é que para um robô - não há outra forma de explicar (e não lhe explicará de outra forma) excepto através de probabilidades derivadas dos números... - É COMO A ECONOMIA TRABALHOU PARA O MUNDO - com os números 0 e 1... por isso temos de digitalizar as entradas para obter probabilidades de saída e estabelecer intervalos de confiança (em que confiamos, não necessariamente estatísticas)... e podemos confiar em tudo (é subjectivo) - ou na lógica binária ou também no resultado ponderado desta lógica binária (aka % probabilidades de toda a gama de soluções potenciais)... -- é apenas uma questão de gosto e hábitos, não um assunto para uma discussão sobre a busca do Graal...
(e entrar numa floresta ou entrar numa rede neural já é um pormenor)
ninguém proibiu a utilização conjunta de árvores/floresta e redes neuronais dentro do mesmo projecto. - a questão é Onde aplicar o quê e quando (velocidade e memória são importantes), não qual é melhor... - é melhor não perder tempo - o equivalente a "tempo fora de uma transacção é tempo perdido, tal como uma transacção fora de tempo é uma transacção desconhecida".
Nenhum modelo pode obter mais do que probabilidades (o que é uma vantagem e uma desvantagem de qualquer digitalização), mesmo que essas probabilidades não sejam ponderadas... Não me enveneno com sanduíches e não aconselho ninguém - ninguém cancelou Bayes (mesmo que não o coloque no código, e especialmente - se o colocar no código)...
p.s. E você deve ser um fã do McDonalds. - hipótese, não a vou verificar...
Algoritmos é mais caro do que as suas conclusões
Nenhum modelo pode obter mais do que probabilidades (o que é uma vantagem e uma desvantagem de qualquer digitalização), mesmo que estas probabilidades não sejam ponderadas... Não me enveneno com sanduíches e não aconselho ninguém - ninguém cancelou Bayes (mesmo que não o coloque no código, e especialmente - se o colocar no código)...
p.s. E você deve ser um fã do McDonalds. - Hipótese, não a vai testar...
O algoritmo é mais caro do que as suas conclusões.