Fazendo um sistema comercial Python para MT. - página 9
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
Se você pode escrever tudo em MQL, você realmente não precisa de mais nada.
Não posso e nem quero escrever e entrar em detalhes de algoritmos que já estão escritos, praticados e disponíveis. Não quero usá-los diretamente, ao invés de reescrevê-los ou adaptá-los à sua aplicação em MQL. A propósito, este é o principal conceito do OOP.
Para não entrar no OOP sozinho não é suficiente, precisamos de modelos componentes de intercâmbio e interação entre programas, como OLE->ActiveX->DCOM->.Net, caso contrário sempre teremos que manobrar entre idiomas e bibliotecas.
Presumo que Python, com suas extensas bibliotecas, não precisará de tudo isso para o futuro próximo. Com exceção da comunicação em terminais, mas esta questão foi resolvida há muito tempo e até mesmo de várias maneiras.
Honestamente, este Python é irritante, juntamente com suas aulas. Aqui está apenas um pequeno trecho de uma das funções:
Conte quantas vezes a palavra self é repetida neste pequeno pedaço de código ?
E o tempo todo e em todos os lugares, em todas as linhas, várias vezes. Este absurdo será repetido em todas as funções (métodos) de qualquer classe o tempo todo.
yep... Sim, python é bom apenas como "cola", para roteiros de algumas a algumas dezenas de linhas, então há uma vantagem distinta sobre C++\Java, mas é mais caro implementar OOP multinível em python, mesmo a nível de conveniência, a velocidade de tais bibliotecas está fora de questão. Python é divertido para mostrar princípios em apresentações, etc. É muito "limpo" em aparência de personalização, que obviamente precisa ser escrito em outras línguas, mas escrever algo sério, com fios e GUI em Python é um verdadeiro aborrecimento
O próprio testador é mais interessante porque você pode ter o controle completo do processo, o que é absolutamente essencial para os testes. E o próprio testador é uma construção muito simples.
Não vejo a utilidade de financiar nada, pois o faço somente para mim mesmo.
O testador não tem um algoritmo complicado, mas há muitos lugares onde posso cometer um erro. Mas é claro que usar os desenvolvimentos de outra pessoa não pode ser menos arriscado, pelo menos pelas mesmas razões, e talvez por algumas outras razões relacionadas com as especificidades de "quem se beneficia com isso".
zumbido... Sim, python é bom apenas como "cola", para roteiros de algumas a algumas dezenas de linhas, então há uma clara vantagem sobre C++/Java, mas é caro fazer OOP multicamadas em python, mesmo a nível de conveniência, a velocidade de tais bibliotecas está fora de questão. Python é divertido para mostrar os princípios em apresentações, etc. É muito "limpo" na aparência da personalização, que claramente precisa ser escrito em outras línguas, mas escrever algo sério, com fios e GUI em Python é um verdadeiro pesar.
Por que "uivar..."? Tudo está bem lá em Python, e a velocidade também está bem. Mesmo os loops 55k funcionam bem, na penúltima à última versão. De fato, as libras em Python são rápidas, enquanto Python em si é principalmente para vincular palavras em uma frase.
De modo geral, falar rápido - lento não faz sentido em si mesmo. Se é rápido, para que serve exatamente? Se lento, então de forma semelhante.
O que há com o "sibilante..."? Tudo está bem lá em Python, e com velocidade também. Mesmo os loops 55k funcionam bem, na penúltima à última versão. De fato, as libras em Python são rápidas, enquanto Python em si é principalmente para vincular palavras em uma frase.
De modo geral, falar rápido - lento não faz sentido em si mesmo. Se é rápido, para que serve exatamente? Se lento, de forma semelhante.
55k é migalhas, você precisa contar bilhões, e assim o testador de pitão nativo não funcionará, você terá que escrever e importar a libu sobre as vantagens, e pitão é apenas para chamar e configurar, pois pode ser 100 vezes mais lento.
e "ahem" era sobre "self" e 100500 __****__ métodos e atributos, IMHO eles fazem código muito mais complicado do que mesmo em pluses, e se falamos de threads, eventos e GUI, tudo não é melhor do que com pluses, muito pelo contrário, toda essa "digitação de pato" e coisas assim apenas começando a doer, você precisa ter muita coisa em mente, lembre-se de muita coisa55k é migalhas, você tem que contar bilhões, e portanto um testador de pitões nativo não funcionará, você terá que escrever e importar a biblioteca em plusses, e pitões apenas chamadas e configurações, porque pode ser 100 vezes mais lento.
e "ahem" era sobre "self" e 100500 __***__ métodos, IMHO eles fazem códigos muito mais complicados do que mesmo com pluses, e se falamos de tópicos, eventos e GUI, tudo não é melhor do que com pluses, ao contrário, toda essa "digitação de pato" e coisas assim, pelo contrário, só começa a doer, você precisa ter em mente um monte de coisasNão sei por que preciso de bilhões)). O testador - não tenho reclamações, até agora tudo é rápido, 3 meses se passam em um momento, e não preciso de mais).
Com tudo o mais, acho que concordo, sobre os prós é mais divertido escrever. Mas você não pode realmente modelar sobre os pontos fortes. Acontece: primeiro modelamos em algum lugar em um software, e depois o portamos para as vantagens, escrevemos todo tipo de interfaces para as bibliotecas - é muito cansativo.
E em Python tudo em um pacote, e um ambiente normal para modelagem + todas as libras necessárias, geralmente em C++. Para a estratégia é suficientemente rápido - 15-30 ms não é um atraso para mim. Eventualmente você pode reescrever seções críticas em C, como fazem na NASA. Se houver algum, é claro.
E nada é perfeito em absoluto).
Não sei por que preciso de bilhões)). Testador - Não tenho reclamações, até agora tudo é rápido, 3 meses escorregam em um momento, e não preciso de mais).
Com tudo o mais, acho que concordo, sobre os prós é mais divertido escrever. Mas você não pode realmente modelar sobre os pontos fortes. Acontece: primeiro modelamos em algum lugar em um software, e depois o portamos para as vantagens, escrevemos todo tipo de interfaces para as bibliotecas - é um verdadeiro incômodo.
E em Python tudo em um pacote, e um ambiente normal de simulação + todas as libras necessárias, geralmente em C++. Para a estratégia é suficientemente rápido - 15-30 ms não é um atraso para mim. Eventualmente você pode reescrever seções críticas em C, como fazem na NASA. Se houver algum, é claro.
E nada é perfeito em absoluto).
No contexto da otimização é de bilhões quando centenas ou mesmo milhares de testes são executados em centenas de milhares de barras de minutos. Não somos nossos inimigos esperando horas para buscar um par de índices genéticos simples por um ano de minutos, isso deve ser feito em segundos, enquanto em Python levará muito mais tempo, assim como em caixas pretas com desaceleração deliberada dos cálculos.
E píton em geral é uma ferramenta muito atraente no contexto certo, embora IMHO sua popularidade atual seja um fenômeno transitório, é algo como a moda nas redes sociais e nos gadgets da Apple, há uma conexão com o brilho exterior e o minimalismo em exemplos muito simples, e também os estudantes que inflacionam suas classificações.
PS A propósito, o que o faz pensar que seu testador está funcionando corretamente? O testador é uma coisa complicada....
Bilhões no contexto da otimização quando o teste é executado centenas ou até milhares de vezes em centenas de milhares de barras de minutos. Não somos nossos inimigos esperando horas por um par de índices genéticos simples por um ano de minutos, deve ser feito em segundos, mas em Python levará muito mais tempo, bem como em caixas pretas com deliberada desaceleração dos cálculos.
Não estou no negócio da otimização e de todos os tipos de correspondência de parâmetros. Minha metodologia é diferente, mas preciso de um ambiente semelhante ao MatLab, R, SciLab, etc. Python é igualmente bom.
Eu também não preciso de 10 ^6 barras. Para tudo - cerca de 6, no máximo 9 meses em minutos é suficiente. Agora o teste é de 3 meses -2,5 m, embora o sistema ainda não seja tão complicado.
O mais longo é aprender ML, mas não há nada melhor do que Python, e aqui é apenas como uma linguagem de scripting. Digamos que a resposta de uma rede neural treinada de 5 camadas, cerca de 60 neurônios é de 3-5 ms.
Até agora, não vejo nenhuma prova real do alarmismo.