Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 2807
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
Eu o troquei e parecia estar tudo bem.
.
.
Seu script consome quase 9 gigabytes de RAM em minha amostra, mas parece funcionar, os arquivos são salvos. Nem sei onde a memória é consumida, enquanto a amostra consome um pouco mais de um gigabyte.
.
Também descobri que os cabeçalhos da tabela (nomes de coluna) são salvos entre aspas - como desativar isso?
O que esse código faz? Para torná-lo mais rápido, você deve converter todas as colunas para o mesmo tipo de dados (float 32, 16 - não é necessário, será mais lento) e calcular o coRRR por meio de matrizes rápidas.
Se estivermos falando sobre a correção real do kaRma
Seu script consome quase 9 gigabytes de RAM em minha amostra, mas parece funcionar, os arquivos são salvos. Nem sei onde a memória é usada, enquanto a amostra consome um pouco mais de um gigabyte.
E daí?
Provavelmente ruim)
Também encontrei um problema - os cabeçalhos da tabela (nomes das colunas) são salvos entre aspas - como desativar isso?
O que você fez para resolver o problema?
E daí?
R é ruim, eu acho).
O que você fez para resolver o problema?
Ruim/bom é um julgamento muito crítico.
É óbvio que o código do pacote não é eficiente em termos de memória, mas pode ser rápido, ou que o script copia a tabela inteira\seleção várias vezes.
E o que você fez - encontrou o problema e o relatou a um profissional que esperava ajuda.
O que esse código faz? Para aumentar a velocidade, você deve converter todas as colunas para o mesmo tipo de dados (float 32, 16 - não é necessário, será mais lento) e calcular o número de colunas usando matrizes rápidas.
Se estivermos falando sobre a correção real do kaRma
Pelo que sei, não há nenhum conceito de tipos de dados diferentes (int, float, etc.) no R. E isso reduzirá o tamanho da memória, mas não afetará muito a velocidade. Nas placas de vídeo, sim, haverá um aumento.
Pelo que sei, no R não existe o conceito de tipos de dados diferentes (int, float etc.). E isso reduzirá o tamanho da memória, mas não afetará muito a velocidade. Nas placas de vídeo, sim, haverá um aumento.
Tudo está lá. Isso afetará a velocidade de forma catastrófica. Os dataframes são os animais mais lentos e com maior sobrecarga.
Não se trata de placas de vídeo, mas de entender que essas coisas não contam com os dataframes em um estado sóbrio.
Dica: é necessário usar vetores de 100.000 observações para ver a correlação entre eles?
Estou procurando vetores altamente correlacionados, ou seja, com correlação maior que 0,9.