Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 297
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
aplicar(embed(padrão, comprimento(sinal)), 1, cor, y = sinal, método = 'pérola')
Obrigado! Imagino o quanto R conta assim. Eu medi o algoritmo da bibla com um comprimento de sinal de 1.000.000 e um padrão de 100.000 - 1 segundo.
Um milhão de vezes mais rápido! E daí? Os sistemas de negociação medem como processadores?
Um milhão de vezes mais rápido! Então, o quê? Os sistemas de negociação são medidos como processadores?
Você tem algum tipo de complexo.
Não, não é um complexo.
μl e R são sistemas completamente diferentes e não sobrepostos. E o que há para comparar? E você não é o único!
μl e R são sistemas completamente diferentes e não sobrepostos. E o que há para comparar? E você não é o único!
Eu estava interessado apenas na velocidade de realização de tarefas estatísticas não raras em qualquer uma das línguas.
R é a linguagem estatística mais popular e há muitos usuários dela. É por isso que a questão da comparação é colocada aqui.
O algoritmo de implementação e, consequentemente, a sua eficiência é de interesse. Não importa a língua em que está escrito.
Eu só estava interessado na rapidez de implementação de uma tarefa estatística não raro em qualquer uma das línguas.
R é a linguagem estatística mais popular e muitas pessoas aqui conhecem-na. É por isso que a questão da comparação é colocada aqui.
O algoritmo de implementação e, consequentemente, a sua eficiência é de interesse. Não importa a língua em que está escrito.
MT é um terminal de negociação. Então eu, aqui neste site e neste tópico, estou discutindo o desenvolvimento do TS. Mas sempre encontramos pessoas discutindo alguns truques de programação que praticamente não têm efeito nos resultados comerciais. A própria função de correlação é útil em outros algoritmos.
Esta função pode ser usada em blocos de decisão de negociação (pelo menos eu a uso), mas sua velocidade de execução não tem nenhum papel, porque o tempo principal para o cálculo de um sinal de negociação é determinado por outros algoritmos computacionalmente complexos que não estão presentes em mql.
Isso está na fase de execução.
Se considerarmos o estágio de desenvolvimento do TS, R é principalmente superior ao µl, pois é um intérprete, o que é muito útil no estágio em que o algoritmo não é muito claro e precisamos tentar muitas variantes, por exemplo, para comparar correlações de pares de moedas. Em R o tempo para verificar a correlação é uma pancada no teclado, com um par de linhas, incluindo uma formação muito útil de vectores iniciais.
Esse era o ponto que eu estava fazendo, que não faz sentido comparar a velocidade de execução dessas funções e, em geral, quaisquer outras funções implementadas no mcl e R.
PS.
Mas a tua biblioteca salvou-me de estudar o Mcl5, obrigado por isso.
MT é um terminal de negociação. Assim sendo, eu, aqui neste site e neste tópico, discuto o desenvolvimento do TS. Mas encontramos sempre pessoas a discutir os truques de alguns programadores que quase não têm efeito nos resultados das trocas. Na verdade a sua pergunta é a mesma porque a própria função de correlação faz sentido em outros algoritmos.
Anteriormente, algumas ideias não podiam ser testadas pelo TC, uma vez que era dificultado pelo baixo desempenho de alguns algoritmos. Neste caso foi exatamente isso que aconteceu - um algoritmo alternativo permitiu ao otimizador explorar uma idéia que é tão antiga quanto o mundo, mas que não pôde ser computada anteriormente em um tempo razoável.
Quando se tem de calcular centenas de biliões de CQ Pearson em padrões de alguns milhares de comprimento, a baixa velocidade de uma tarefa aparentemente simples torna-se um estrangulamento insuperável. Pode-se começar a dizer que se um problema parece muito pesado computacionalmente, é um problema mal formulado com pouca compreensão. Talvez seja. Mas o que está feito, está feito. E é sempre interessante ver como os outros implementam tais coisas.
É melhor gastar um pouco mais de tempo no desenvolvimento, mas depois calcular sempre rapidamente, ou desenvolver-se rapidamente e depois suportar sempre um cálculo lento?
Se R é rápido de desenvolver mas lento de calcular, então onde você calcula? Para desenvolver rapidamente um supercarro que seja lento? Você não precisa de um supercarro.
Eu só estava interessado na rapidez de implementação de uma tarefa estatística não raro em qualquer uma das línguas.
R é a linguagem estatística mais popular e muitas pessoas aqui conhecem-na. É por isso que a questão da comparação é colocada aqui.
O algoritmo de implementação e, consequentemente, a sua eficiência é de interesse. Não importa a língua em que está escrito.
Bem, em um sinal de comprimento 1000000 e um padrão de comprimento 100000 é improvável que a implementação conte em tempo razoável, porque seria necessário criar uma matriz de tempo 900001x100000 :D Mas levou menos de 30 segundos para escrevê-la, e até algum tamanho de tarefa será bastante aplicável. Podemos implementar a mesma coisa com fft/convolve, nesse caso precisaríamos escrever mais código, mas a velocidade de execução não seria muito inferior ao código C.
Em R é muito conveniente fazer protótipos de modelos complexos - este é o seu lado forte. A performance do código é uma questão de habilidade e experiência:
1. Algumas construções e tipos de dados R funcionam mais rapidamente que outras (tipos mutáveis vs imutáveis (lista vs ambiente), para vs lapply/sapply/etc., S4 vs R6).
A facilidade de paralelização em R para alguns problemas permite obter uma solução de código lento mais rápido do que seria necessário para escrever código rápido em outro idioma + computação.
3. As operações individuais no idioma são feitas de forma universal, mas ineficiente. Se você implementar funções pequenas mas computacionalmente pesadas em C++, você pode obter resultados tremendos sem reduzir a velocidade de desenvolvimento tanto quanto no caso de escrever o código inteiro em uma linguagem tipo C. Por exemplo, somar itens de matriz em linhas ou colunas em R pode ser de 4 a 15 vezes mais rápido do que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).
Bem, em um sinal de 1000000 comprimento e 100000 comprimento padrão que a implementação dificilmente pode ser calculada em um tempo razoável, porque seria necessário criar uma matriz de tempo 900001x100000 :D Mas levou menos de 30 segundos para escrevê-la, e até algum tamanho de tarefa será bastante aplicável. Poderíamos fazer a mesma coisa com fft/convolve, nesse caso precisaríamos escrever mais código, mas seria tão rápido quanto o código C.
R é muito bom a fazer protótipos de modelos complexos - essa é a sua força. A velocidade do código é uma questão de habilidade e experiência:
1. Algumas construções e tipos de dados R são mais rápidos que outras (tipos mutáveis vs imutáveis (lista vs ambiente), para vs lapply/sapply/etc., S4 vs R6).
A facilidade de paralelização em R para alguns problemas permite obter uma solução de código lento mais rápido do que seria necessário para escrever código rápido em outro idioma + computação.
3. As operações individuais no idioma são feitas de forma universal, mas ineficiente. Se você implementar funções pequenas mas computacionalmente pesadas em C++, você pode obter resultados tremendos sem reduzir a velocidade de desenvolvimento tanto quanto no caso de escrever o código inteiro em uma linguagem tipo C. Por exemplo, somar itens de matriz em linhas ou colunas em R pode ser de 4 a 15 vezes mais rápido do que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).