Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 298
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
É melhor gastar um pouco mais de tempo no desenvolvimento e depois calcular sempre rapidamente, ou desenvolver-se rapidamente e depois suportar sempre os cálculos morosos?
Se você se desenvolve rapidamente em R, mas é lento para calcular, onde você quer fazer o cálculo? Rápido para desenvolver um supercarro que seja lento a conduzir? Você não precisa de um supercarro.
Nas tarefas de pesquisa é a velocidade de desenvolvimento que vem à tona. Ao invés de uma pessoa que escreve código super rápido mas testa 1 hipótese por dia, uma pessoa que escreve código lento e executa cálculos a noite toda, mas tem 20 hipóteses testadas até o dia seguinte, é facilmente contratada.
Para a produção-implementação do modelo é mais fácil contratar outra pessoa com um pequeno salário, que irá reescrever os modelos mais promissores na linguagem mais rápida possível. Há muitos programadores e a competição é alta, mas os investigadores que conseguem arranjar algo novo são difíceis de encontrar :P
É uma prática comum. Procure empregos como pesquisador quantitativo e desenvolvedor quantitativo. O primeiro geralmente precisa de R/Python, o segundo geralmente precisa de C++/Java.
Nas tarefas de pesquisa, é a velocidade do desenvolvimento que vem à tona. Ao invés de uma pessoa que escreve código super rápido, mas verifica 1 hipótese por dia, você pode contratar uma pessoa que escreve código lento e o executa a noite toda, mas no dia seguinte ele tem 20 hipóteses verificadas.
Para a produção-implementação do modelo, é mais fácil contratar outra pessoa por um pequeno salário para reescrever os modelos mais promissores em uma linguagem rápida. Há muitos programadores, e a competição é alta; mas os investigadores que conseguem arranjar algo novo são difíceis de encontrar :P
É uma prática comum. Procure empregos como pesquisador quantitativo e desenvolvedor quantitativo. O primeiro geralmente tem que conhecer R/Python, o segundo geralmente tem que conhecer C++/Java.
Não seria mais fácil usar bibliotecas C++ prontas e rápidas em vez de usar as mesmas, mas lentas em R para "desenvolvimento rápido"? Você, e muitos outros aqui, fazem constantemente uma substituição de noções. Da mesma forma, pode-se "desenvolver rapidamente" em um ambiente semelhante a C. Ou você não precisa de conhecimentos apropriados em mineração de dados e estatísticas para trabalhar em R? Da mesma forma que você precisa do conhecimento para se desenvolver em C. Então porquê fazer trabalho a dobrar?
E eu não sei de que tipo de "prática normal" estás a falar, mas estou habituado a ir bem de uma vez e de uma vez.
Durante a minha prática de engenharia vi frequentemente pessoas que, por alguma razão, pensavam que se usassem complexos de software super-duper amigáveis ao desenvolvimento, iriam definitivamente sair-se bem... Mas eles não conseguiram entender uma coisa: precisam de outra coisa para que tudo funcione bem: a gordura na cabeça deles.
Não é mais fácil usar bibliotecas C++ rápidas e de prateleira em vez de usar as mesmas, mas lentas em R para "desenvolvimento rápido"? Você, e muitos outros aqui, fazem constantemente uma substituição de noções. Da mesma forma, você pode "desenvolver-se rapidamente" em um ambiente semelhante a C.
A escolha da linguagem é o seu negócio pessoal e certo. Sobre bibliotecas - infelizmente, para qualquer algoritmo moderno ou incomum, você tem que implementar tudo você mesmo. Por exemplo, para calcular "bipower variance" (o que significa isso? :D) não encontrei bibliotecas.
Ou não se precisa de conhecimentos apropriados em mineração de dados e estatísticas para trabalhar em R?
Eu não digo isso e não apoio esta opinião.
E eu não sei de que tipo de "prática comum" estás a falar, mas estou habituado a fazer bem de uma vez e de uma vez.
Durante a minha prática de engenharia, muitas vezes vi pessoas que, por alguma razão, pensavam que se usassem pacotes de software super-duper amigáveis ao desenvolvimento, iriam definitivamente dar-se bem... Mas eles não conseguiam entender uma coisa - precisavam de algo mais para que tudo fosse bom: a gordura em suas cabeças.
Minha prática em alguns projetos com complexidade ## man-years, onde 95% do código é escrito em R, mostra que ferramentas diferentes são boas para tarefas diferentes, às vezes até lentas, desde que sejam usadas para protótipos e não para produção. A utilização de diferentes ferramentas em diferentes fases de desenvolvimento é uma prática comum na indústria de desenvolvimento e é confirmada pelos requisitos de especialistas para diferentes trabalhos. Os projetos que mencionei teriam se tornado muito mais complexos se fossem implementados em uma linguagem tipo C, mesmo por soldados universais que sabem e podem fazer tudo e escrever a solução do problema de uma só vez, sem nenhuma fase de pesquisa.
Por isso, peço a minha licença.
Não é mais fácil usar bibliotecas C++ rápidas e de prateleira em vez de usar as mesmas mas lentas em R para 'desenvolvimento rápido'?
Quando se discute o R I sempre se baseou numa avaliação abrangente e sistemática deste "sistema gráfico e estatístico". a linguagem algorítmica em si não é de todo mencionada no título.
Uma comparação frontal da performance do código em R e como acima código em µl, ou outra linguagem de programação, em um exemplo local específico, NÃO é completamente correta, pois TC nunca consiste como discutido acima em uma função de correlação, mas é sempre um conjunto grande que consiste em código e chamadas de função. Como R tem um conjunto enorme de funções, o código normalmente tem um pequeno número de linhas (1000 linhas é muito), mas com um conteúdo muito capacitivo.
O programa em si, que resolve algum problema significativo, pode ser dividido, grosso modo, em duas partes:
No ponto 1, se for necessário escrever quantidades significativas de código, então a questão da velocidade pode ser muito séria. Há três maneiras de superar isso:
No item 2, o desempenho é bastante diferente e eu duvido que sem esforços especiais no desenvolvimento normal do programa µl ele possa superar o R no desempenho.
Por exemplo.
Na superfície, operações sobre vetores e matrizes em R são básicas. Uma expressão da forma a <- b*c é executada pela biblioteca da Intel. Não há laços. Está disponível para todos, não é necessário nenhum conhecimento ou esforço adicional. Ao desenvolver um programa μl, os ciclos provavelmente serão utilizados, embora também seja possível consultar a mesma biblioteca (se o programa não for para o mercado), mas é necessário um nível bastante elevado de conhecimento e esforço para alcançar o mesmo resultado.
Mas isso não é tudo.
Se abordarmos algoritmos computacionalmente pesados, e estes são apelos às funções R, o próprio desenvolvedor, diante do problema de desempenho, tem se preocupado com este problema e geralmente o resolve na fase de desenvolvimento. Isto normalmente é resolvido escrevendo código C ou referindo-se às bibliotecas C ou Fortran. Além disso, tais algoritmos têm entre seus parâmetros a possibilidade de especificar o uso de muitos núcleos. Um desenvolvedor em R recebe tudo isso automaticamente sem esforços. Pode-se concentrar totalmente na essência da TC, não na técnica de implementação. É duvidoso que o desenvolvedor do programa μl possa superar o desenvolvedor de funções em R pela razão trivial - é necessário trabalhar especificamente no desempenho, mas não na essência do TC.
De tudo o que foi escrito resulta que uma comparação correcta de desempenho seria escrever código TC real em µl e o mesmo código em µl+R (não há ordens de negociação em R) e comparar. Mas em toda a sua glória - será que precisamos dele?
Alguém tentou trabalhar com parcelas de recorrência? Pode ler sobre isso aquihttps://habrahabr.ru/post/145805/, em particular para substituir os MOs em vez dos BPs crus? pode funcionar como uma opção
e mais para lerhttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Uma ideia para aqueles que a podem implementar. A visão da máquina compara estas parcelas à procura de correspondência de padrões. Como um substituto para a correlação inútil
Uma ideia para aqueles que podem implementar isto. Comparação máquina-visão destas parcelas em busca de correspondência de padrões. Como um substituto para a correlação inútil.
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 no otimizador explorar uma idéia que é tão antiga quanto o mundo, mas que não pôde ser computada previamente 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 coisas semelhantes.
E se você o implementar também na GPU, você será realmente valioso))
Sem ponzi você pode encontrar o padrão mais freqüente. Mas qual é o objectivo?
Bem, para uma estratégia padrão, claro ) não necessariamente a mais frequente, pode haver muitas variantes
Não necessariamente o mais frequente para as estratégias padrão, pode haver muitas variantes.
Isto é o que eu não entendo. O uso de dados padrão é útil ao comprimir dados com pouca perda de informação (vários meios). Mas o que é que isto tem a ver com o TC?
A maneira mais fácil de falar sobre este tópico é usar o padrão mais frequente como exemplo. Não é uma tarefa difícil encontrá-la.
Aqui está algum enigma (padrão) que ocorre com mais frequência. O seu critério de selecção não é tão importante neste momento. Que o enigma esteja lá. Como utilizá-lo para negociação?
Dizer que se uma história ultraperiférica coincide com uma zagagulina nos primeiros 80%, então os próximos preços seguirão o mesmo padrão que os restantes 20% da zagagulina é um disparate.
Isto é o que eu não entendo. O uso de dados padrão é útil ao comprimir dados com pouca perda de informação (vários meios). Mas o que é que isto tem a ver com o TC?
A maneira mais fácil de falar sobre este tópico é usar o padrão mais frequente como exemplo. Não é uma tarefa difícil encontrá-la.
Aqui está algum enigma (padrão) que ocorre com mais frequência. O critério para a sua selecção não é tão importante neste momento. Que o enigma esteja lá. Como utilizá-lo para negociação?
Dizer que se uma história ultraperiférica coincide com uma zagagulina nos primeiros 80%, então os seguintes preços irão no mesmo sentido que os restantes 20% da zagagulina é um disparate.
Por que você acha que é um absurdo? Se a previsão será confirmada, no mesmo histórico, em uma massa de casos