Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 17
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
Tenho de acreditar na vossa palavra?
e nunca concordará com ele.
ele não lidou com a sua tarefa. por isso está a acumular complicações "virtuais" para justificar as suas palavras.
esquecê-lo e seguir em frente.
Onde se encontra a rede de arrasto?
ou ainda está no mercado? porque uma rede de arrasto precisa de uma posição actual.
Introduziria também um indicador de volatilidade e colocaria mais um bloco para corrigir paragens de protecção, nomeadamente paragens de protecção porque (imho) a saída por TP ou SL é uma força maior para um TS normal.
Concordo absolutamente com a força maior, é por isso que não trabalho com eles. Apenas os de protecção.
Pensei na previsão da volatilidade, mas ainda não o fiz. Se for feito, fornecerá informação ao condutor, por si só. :)
e nunca concordará com ele.
Ele não lidou com o seu problema, por isso está a criar dificuldades "virtuais" para justificar o que diz.
Esqueça-o e siga em frente.
Não estou a tentar, nem sequer estou a escrever para ele ;-)
Apenas me ajuda a fazer uma espécie de FAQ sobre netting aqui mesmo. como um co-autor. )))
// Todas as perguntas/assultos são suficientemente previsíveis. Todas as respostas a elas têm sido discutidas há muito tempo durante cem quilómetros nas proximidades. Nada de novo.
// "Tenho o tipo de respostas sobre as quais ninguém vai sequer fazer uma pergunta..." (ц)
...
// "Tenho o tipo de respostas sobre as quais ninguém vai sequer fazer uma pergunta..." (ц)
Tais perguntas seriam mesmo interessantes de ouvir sem respostas. )))
Sugiro voltar a discutir os princípios gerais da programação de grandes projectos.
Um dos princípios é chamado"abstracção de dados":
O sistema não deve depender do formato dos dados de entrada e saída.
A sua função é fazer os cálculos correctos, alimentando as entradas com sinais universais e produzindo sinais universais para as saídas.
Neste caso, o sistema não precisará de mudar quando estes formatos mudarem.
A adaptação aos formatos é fornecida por conversores/conversores ao nível da interface do sistema.
Como podemos ver:
Qualquer consultor especialista de minas construído de acordo com o esquema descrito segue cuidadosamente este princípio e, por exemplo, pode ser portado para MT4 imediatamente após a actualização da linguagem de programação para mql5, simplesmente substituindo o motor de mercado e os indicadores de entrada.
Todos os EAs construídos de acordo com o seu esquema terão de ser completamente reescritos. Lamento, mas o facto é que existe.
Todos os EAs baseados no seu esquema terão de ser completamente reescritos. Lamento, mas o facto é que existe.
Não se os sistemas de negociação 1) derem ordens de negociação através do módulo de gestão de estratégias 2) utilizarem apenas os dados fornecidos pelo módulo de gestão de estratégias. O módulo em si terá de facto de ser reescrito, assim como o condutor.
O motor do comércio reduz a fiabilidade do sistema.
Não há necessidade de um medidor de volatilidade. Faz parte do TS.
Oh, Vladimir, não é tão fácil com o seu circuito. Está a dizer que só precisa de reescrever o condutor? Bem, contei muito mais peças dependentes de plataformas:
Como obter a história do mercado e a história do comércio? E a informação sobre a posição actual não será, por acaso, retirada do terminal? E se tiver de implementar o módulo de volatilidade - mais um API dependente da plataforma?
Vai escrever adaptadores? Quantos deles existirão? Para o histórico do mercado - um adaptador, para o histórico de negociação - outro, para trabalhar com as posições - um terceiro, pelo que no final há o dobro de módulos, e a mesma quantidade de código dependente da plataforma.