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
Resultado:
Ou estou a fazer algo errado (por favor, corrigir), ou o MetaDriver cometeu um erro em teoria (ao conceber o algoritmo).
:)
Bem, considerando o facto de o algoritmo "concepção" ter demorado cerca de 3 minutos (e 7 minutos de implementação), fiz bastante bem :) O objectivo era mostrar uma ideia de trabalho e clarificar a declaração do problema.
E tudo isto se revelou útil - os criadores tiveram uma oportunidade real de melhorar a função MathFloor() - obviamente que não é inteiramente implementado de forma limpa.
No final, tiveram de mexer com ela. Foi divertido. Só consegui obter uma função estável (quero dizer CountSignedDigits(duplo x)) após quase uma hora de experiências.
E mesmo agora não tenho a certeza se vai funcionar correctamente com todos os valores de entrada. Não desenvolvi um teste de stress automatizado, fiz um teste manual. Por favor, teste-o.
Espero uma operação estável até 10 casas decimais após a vírgula flutuante.
O teste de stress anexado. // Não removi algumas realizações intermédias do código. Deixei-o em comentários para que tentasse/pensasse. Incluindo os criadores.1. não é preciso definir cavar por muito, basta normalizá-lo para o passo certo:
2. mesmo que haja algum lixo na variável do lote ao enviar um pedido comercial (na casa decimal), este deve ser descartado pelo próprio terminal.
Pelo menos, não tive quaisquer problemas durante vários anos de utilização de uma tal construção.
4. se quiser segurar, pode normalizá-lo até 8 casas decimais (com uma margem) - se houver lixo após a normalização "correcta", será muito mais longe.
A primeira ideia é correcta, as outras são suspeitas. :)
A implementação é exequível para a prática, mas para as condições artificiais definidas por "iniciador de problemas" (c) é imprecisa. Para passos discretos gera não em relação ao lote_min, mas em relação ao zero. :)
No entanto, pode ser facilmente reparado se o notar.
// Por favor, não leve todas estas pérolas demasiado a sério. Os esclarecimentos são puramente teóricos, para a formação do cérebro, porque na prática nunca vi o lote_step igual a, digamos, 0.0231....
;)
a opção está correcta. Correctamente contabilizado por lot_min como no meu NL().
A minha variante também está disponível. Note-se que para alguns instrumentos a etapa de mudança de preço é maior do que o ponto.
Se assumirmos como axioma que os passos "vão" não de zero, mas do lote mínimo, o algoritmo correcto é o seguinte:
Na versão Composter, os passos "vão" a partir do zero. O que não me parece correcto.
Na variante MetaDriver, o código salta um valor negativo. =Р
...
Na variante MetaDriver, o código salta um valor negativo. =Р
:)) ..... Ah, sim! Não vai trabalhar de todo! ;-R ;-b ;-R
Bem, se alguma coisa, a variante mais curta e ao mesmo tempo "mais ou menos precisa" é esta:
E isso sem verificar a nulidade e negatividade de lote_step, lote_min e lote_max!! ......
:))))
Uh.... atingir um nervo. :)) A última linha foi corrigida à mão num post do fórum, por isso, perdoem-me. =)
A propósito, o seu código também não foi compilado (esqueci-me de colocar um parêntese de fecho na última linha). :-Р
Além disso, é 2-3 vezes mais lento (agora verifiquei-o no guião), mas a qualidade do controlo é a mesma. :-Р
De qualquer modo, enquanto não houver um código adequado para determinar o inteiro significativo, vou seguir o conselho do Composter: normalizar o volume para 8 casas decimais.
Esperemos que não haja armadilhas.
Obrigado a todos pela vossa ajuda.
vocês são engraçados, estou a ver.
no seu primeiro post deu NL() o que só chegou a duas páginas mais tarde ;)
Há outra questão para os gurus. Quando testo a moeda múltipla, recebo erros (imagem do ecrã anexada).
Estou a tentar fazer uma operação comercial, mas recebo uma resposta: Sem preço. De acordo com o testador pode ser visto que as citações para este par começam a chegar em 2011.01.0301:00:00, enquanto EURUSD também é citado a partir de 2011.01.0300:00:00 Existe alguma maneira de descobrir a hora do início das citações para contornar este erro?
Há outra questão para os gurus. Quando testo a moeda múltipla, recebo erros (imagem do ecrã anexada).
Estou a tentar fazer uma operação comercial, mas recebo uma resposta: Sem preço. De acordo com o testador pode ser visto que as citações para este par começam a chegar em 2011.01.0301:00:00, enquanto EURUSD também é citado a partir de 2011.01.0300:00:00 Existealguma forma de descobrir a hora do início das citações para evitar este erro?