Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 1196
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
Lindo!
Pergunta como especialista em Python, me dê algo em Python para experimentar, eu quase peguei o jeito de Sharp, ele se liga ao MT5 sem nenhum problema, C# e Python devem suportar, então eu posso mudar para Python ;)
Python não tem nada a ver com o nosso problema. Python é uma pilha de tudo e qualquer coisa que possa ser útil para nós, um subplot redneck com versões obscuras que não são compatíveis de cima para baixo. O apoio da Python é puramente rústico, sobre os entusiastas. As rubricas de pacotes aceitáveis em Python não existem como tal. Qualquer coisa para encontrar em Python é uma busca no fórum, por entusiastas.
Isto é especialmente claro quando se compara Python com R. R é o nosso, sistema de trader, com um excelente aparelho de referência e a nossa rubrica. Não há nenhum problema em encontrar as ferramentas que você precisa. Cada pacote está bem documentado: descrições de chamadas de funções, links para algoritmos que implementam essas funções, exemplos, links para artigos relacionados ao pacote. R pode ser usado como um livro de texto sobre qualquer problema. E todo o material é absolutamente concreto, apoiado pelo código correspondente.
Python não tem e não pode ter uma vantagem sobre R porque tudo que é interessante para nós é escrito em Cp, enquanto Python ou R são os shells para estes pacotes. Às vezes Python está à frente do novo pacote, devido à completa falta de requisitos de design para os pacotes e o suporte subsequente. Tudo o que aparece nos espelhos R é moderado e o lixo é filtrado.
O lado oposto do R é Srr, o próprio R está escrito em Srr, tem uma interface perfeitamente documentada entre R e Srr. Assim é sempre possível largar a shell R e utilizar directamente a ferramenta em si, escrita em Srr, a partir de programas no MCL.
Uma última coisa. Tanto quanto sei, ainda não há ponte entre Python e MCL. Mas essa ponte entre R e ambos os MCLs existe há muitos anos, está disponível gratuitamente em kodobase, e não há reclamações - tudo funciona de forma estável, o testador funciona e eu ainda não vi nenhuma reclamação sobre velocidade: os dados são enviados em memória.
A Python não tem nada a ver com os nossos problemas. Python é uma pilha de tudo e qualquer coisa útil para nós, um subplot de pescoço vermelho com versões incompreensíveis que não são compatíveis de cima para baixo. O apoio da Python é puramente rústico, sobre os entusiastas. Rubricas de pacotes aceitáveis em Python não existem como tal. Qualquer coisa para encontrar em Python é uma busca no fórum, por entusiastas.
Isto é especialmente claro quando se compara Python com R. R é o nosso, sistema de trader, com um excelente aparelho de referência e a nossa rubrica. Não há nenhum problema em encontrar as ferramentas que você precisa. Cada pacote está bem documentado: descrições de chamadas de funções, links para algoritmos que implementam essas funções, exemplos, links para artigos relacionados ao pacote. R pode ser usado como um livro de texto sobre qualquer problema. E todo o material é absolutamente concreto, apoiado pelo código correspondente.
Python não tem e não pode ter vantagem sobre R porque tudo o que é interessante para nós é escrito em Cp, enquanto Python ou R são os shells para estes pacotes. Às vezes Python está à frente do novo pacote, devido à completa ausência de requisitos de design e manutenção de pacotes. Tudo o que aparece nos espelhos R é moderado e o lixo é filtrado.
O lado oposto do R é Srr, o próprio R está escrito em Srr, tem uma interface perfeitamente documentada entre R e Srr. Assim é sempre possível largar a shell R e utilizar directamente a ferramenta em si, escrita em Srr, a partir de programas no MCL.
Uma última coisa. Tanto quanto sei, ainda não há ponte entre Python e MCL. Mas tal ponte entre R e ambos os MCLs existe há muitos anos, está disponível gratuitamente em kodobase e não há reclamações - tudo funciona estável, o testador funciona e eu ainda não vi nenhuma reclamação sobre velocidade: os dados são enviados em memória.
Eu também prefiro R, mas acredito que o futuro no nosso campo está em píton. Você pode construir um sistema completo de ciclo fechado sobre ele, desde a análise até a negociação. Um exemplo é o quantopian. Isso não vai funcionar para o R.
Eu também prefiro R, mas acredito que o futuro no nosso campo está em python. Ele pode ser usado para criar um sistema completamente de ciclo fechado, desde a análise até a negociação. Um exemplo é o quantopian. Não vais conseguir fazer isso com o R.
Porque não vai funcionar? Parece-me que já o faz há muitos anos. Existe seu próprio terminal IBrokers que possui um API para o mesmo corretor que o quantopian.
Mais uma vez, Python é a mesma concha que R. Apenas o R é um desenvolvimento sério, enquanto o Python é um "dodgem", há muitos usuários que não são fundamentais para nós e criam ruído.
O lado oposto do R é Srr, o próprio R está escrito em Srr, tem uma interface perfeitamente documentada entre R e Srr. Por isso é sempre possível deixar cair a shell em R e utilizar directamente a própria ferramenta, escrita em Srr, a partir de programas em MKL.
É provavelmente por isso que a ponte para R está escrita em pascal.
Você daria um bom vendedor, parabéns
Daria um bom vendedor, parabéns.
Diga pelo menos um pacote de aprendizagem de máquinas amplamente conhecido e popular (não para você, mas para a comunidade mundial) em R.
Há outros? Não em R? Há quase 200 deles só na carapaça do carpete e não todos, como as próprias keras. Quer que eu recolha estatísticas sobre o seu uso na comunidade global?
É tudo conversa fiada como qualquer conversa sobre selecção de linguagem de programação. Eu não sou fã de podlouches. E para mim esse é o critério decisivo. A cada um o seu.
Há outros? Não em R? Há quase 200 deles só na carapaça do carpete e não todos, como as próprias keras. Quer que eu recolha estatísticas sobre o seu uso na comunidade global?
É tudo conversa fiada, como qualquer conversa sobre a escolha da linguagem de programação. Eu não sou fã de podlouches. E para mim esse é o critério decisivo. E lá para cada um o seu.
Bem, eu vejo que eles estão começando a adicionar R, como TFlow e MXnet, antes de ser apenas píton.
É provavelmente por isso que a ponte para R está escrita em Pascal.
Que diferença faz aquilo em que está escrito?
A ponte foi escrita há 10 anos, na época em que era usada para ensinar programação aos alunos. Depois a Pascal morreu de repente.
Mas a principal vantagem da ponte - a primitividade, não requer tempo para dominar.
Eu até abri uma filial aqui, agitado para escrever algo mais decente, até formulou o ToR, mas ninguém quer, então o que nós temos, nós temos. Python também não tem isso.
Ok, vejo que eles começaram a adicionar R, como TFlow e MXnet, antes de ser apenas píton.
Escrevi no fórum: não vejo nenhum benefício em substituir um pacote por outro. Todo o problema são os preditores e sua capacidade preditiva para um determinado professor. Se este problema for resolvido, então ao custo do pacote você pode se livrar de alguns por cento do erro, mas não vale a pena o problema.