Minha abordagem. O núcleo é o motor. - página 38
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
Bem, bem... Vá em frente, Peter.
Você está certo sobre 'degradação', mas eu acho que você é presunçoso sobre 'puxar usuários'.
Mas, vá em frente. Pode haver alguém por aí que saiba programar, mas que trabalhe "de mãos dadas".
Estou pensando, existe uma famosa plataforma americana para o comércio manual. Ela tem a possibilidade de automatizar parcialmente as ações dentro da plataforma, mas você tem que saber como fazê-lo. Há também um API. Mas quantos irão administrá-lo?
Podemos escrever semiautomáticas úteis e oferecê-las aos clientes. E não apenas eles. Todos os comerciantes que comercializam manualmente, podemos oferecer uma automação parcial das ações, observar o mercado a partir de tabelas e interagir com o programa usando janelas de diálogo. Exibir mensagens sobre eventos de mercado. Bem, talvez eu não saiba ou não entenda alguma coisa, mas em teoria?
Nós, por outro lado, podemos escrever semiautomáticas úteis e oferecê-las aos clientes. E não apenas eles. Podemos oferecer a todos os comerciantes que comercializam manualmente automação parcial de suas ações, observar o Mercado a partir de tabelas e interagir com o programa através de janelas de diálogo. Exibir mensagens sobre eventos de mercado. Bem, talvez eu não saiba ou não entenda alguma coisa, mas em teoria?
Só há uma maneira de descobrir.
Finalmente, ao menos publique algo.
Que seja menos que ideal e sem plushkas (se necessário, acrescentar mais tarde), e imediatamente ver a demanda + feedback dos usuários irá e será mais claro em que direção cavar em seguida.
Quanto mais cedo você fizer isso, mais tempo você economiza (ou melhor, menos tempo você perde... :(
Eu teria dado muito por tal conselho em meu tempo :)
Bem, bem... Vá em frente, Peter.
Você está certo sobre a "degradação", mas eu acho que você está sendo presunçoso sobre "puxar usuários".
Mas, vá em frente. Pode haver alguém que saiba programar, mas que comercialize "de mãos dadas".
Isso não é possível. Aqueles que sabem programar certamente farão um assistente na MQL5 e passarão apenas 1-2 semanas estudando as operações comerciais da MQL5.
Quanto ao robô semi-automático, em poucas horas farei um vídeo e mostrarei como é um robô automatizado moderno que pode funcionar em modo semi-automático como um Expert Advisor.
E não é preciso inventar painéis complicados para isso, mas fazer um muito simples para torná-lo mais claro para todos.
Os usuários de hoje estão degradados pelo graal do teste. Eles precisam ser puxados para um pouco de complexidade e responsabilidade por suas ações. Caso contrário, uma completa degradação de algotrading.
Não vejo nenhum outro futuro para o nicho do algotrading. Honestamente, eu não vejo...
Tanto pathos... Vejo as mãos levantadas de dor ;))))
Você, Petya, realmente gosta do papel do Messias.
Todos estão degradados... ao que o mundo está chegando... sua missão, seu destino é levar uma humanidade degenerada a um futuro brilhante de algotrading. Já existe aqui um diagnóstico. Fora de sua cabeça...
Petya, não se faça de bobo.
Há algo no mql oop que eu pessoalmente não gosto. Qualquer objeto "vazio" leva 16 bytes. Além disso, seu ponteiro leva 8 bytes. Total 24 bytes por 1 item, sem contar os dados. Se você fizer uma matriz de propriedades, você pode substituir um objeto "vazio" por 6 ints, cada um dos quais pode armazenar quase tudo, exceto cordas (para tempo ou preço uma int é suficiente em 99% dos casos)
E a operação de conversão do tipo dynamic_cast não é barata em termos de velocidade. Portanto, o método do iniciador do tópico (eu não o vi, é claro, mas teoricamente) pode funcionar mais rápido e levar menos memória do que o análogo ao OOP.
Ilya Malev:
Portanto, o método do topikstarter (eu não o vi, é claro, mas teoricamente) pode funcionar mais rápido e levar menos memória do que os análogos OOP.
Não pode, o "núcleo" do iniciador do tópico é um conjunto de fios de tamanho imenso, e falar sobre a eficiência de tal abordagem é irrealista, mesmo teoricamente.
E a operação de conversão do tipo dynamic_cast não é barata em termos de velocidade. Portanto, o método do iniciador do tópico (não o vi, é claro, mas em teoria) pode funcionar mais rápido e ocupar menos memória do que seu análogo OOP.
Portanto, ninguém argumenta que o acesso direto a uma enorme gama global é mais rápido do que todos esses artifícios de interface e conversões de tipo. Também podemos pensar em padrões de design, por exemplo, Visitante com duplo despacho - há uma grande quantidade de despesas gerais.
No entanto, tudo isso é compensado pela conveniência de apoio e modificação. Infelizmente, a transferência máxima de qualquer esforço de pensamento para o computador tem sido o principal desenvolvimento de programação por muito tempo. Chega a um ponto em que a soma de uma progressão aritmética é calculada por meio de um loop, em vez de usar a conhecida fórmula de soma. Nesse sentido, concordo com Peter que as pessoas são "degradantes".
Mas, infelizmente, não há escolha - ou você "se degrada" com todos os outros, tentando não fazê-lo tão rápido, ou você está desesperadamente atrasado. E o fato de seu programa ser ineficaz é de pouca importância.
Aqui vejo até uma analogia com a competição em biologia, nas relações entre predador e presa. A lebre, fugindo do lobo, está de fato competindo não com o lobo, mas com outras lebres. Ele não precisa se afastar do lobo o mais rápido possível. É muito mais importante fugir do lobo para não ser o último. Porque se ele for o último a fugir - ele será comido, mas se fugir mais rápido do que todos os outros - ele gastará mais energia do que o necessário, e pode ser gasto em direções mais úteis.
Assim é com todos os tipos de tecnologias de programação... A maneira mais eficiente de programar em assembler, mas requer tanto esforço que não faz sentido - a energia é melhor gasta de forma mais produtiva, mesmo que o código não seja tão eficiente nisso. A matriz de Peter com acesso global é do mesmo tipo. O acesso é eficiente, mas lembrando o que está onde e como acessar o que exige muito esforço.
Não pode, o "núcleo" no início do tópico é um conjunto de cordas de tamanho imenso, e é irrealista, mesmo teoricamente, falar sobre a eficácia de tal abordagem.
É realmente um conjunto de cordas ou é uma figura de linguagem? Se os dados forem representados por cordas mql (string), não há realmente nenhuma chance...
O acesso é eficiente, mas lembrar o que está onde e como acessá-lo leva muito tempo.
Quando o "kernel" estiver pronto, você pode gastar uma quantidade relativamente pequena de esforço para se ater a ele uma interface conveniente que resolva todos os problemas de apresentação "desajeitada" e acesso à informação. Embora esta seja uma conversa ociosa, como eu entendo, a TC não publicou seus códigos e quem sabe se eles estão na natureza :) Ou ele já os postou? Honestamente, eu não consegui passar todas as 38 páginas
Além disso, um método que se limita apenas à "semi-automática" não tem valor por definição. Embora possa ajudar a ocupar um nicho local, limitado no mercado de produtos e freelance