Estimativa das necessidades de margem na MQL5 - página 6
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
Renate, nos portões de Buchenwald foi escrito jedem das Seine
Você não deve impor sua opinião aos outros. Quanto aos outros, eles não têm o melhor deles e sua decisão depende do parâmetro que estão discutindo.
acordado
Dividir o saldo pela margem de 1 lote.
haverá um risco de 100%.
Se você tiver um pedido, divida o patrimônio por 1 lote de margem, ou seja, 100%.
Talvez seja necessário reduzir a propagação.
é por isso que a % de risco está incluída na fórmula.
Eu não escrevi o TS-Ru para nada, como você precisa aprender a contar suas avózinhas...
ps
Você não vai acreditar nisto - o exemplo de código é retirado de uma expo
Eu só tinha que abrir uma ordem de qualquer tipo... para entrar no mercado
mas eu não a afixei...
concordo
dividir o saldo pela margem de 1 lote
é um risco de 100%.
Se houver pedidos, dividir o patrimônio por 1 lote de margem
Eu não escrevi para a TS-Ru lá por nada, como aprender a contar suas avózinhas...
E se não há ordens, então você não pode contar por equidade?
E se não houver pedidos, o capital não pode ser usado?
você pode
ps-coup no posto.
mas eu estava testando tais exposições... calculado no Equi...
é uma morte lenta.
é melhor fazer como a CALM
ele cortou o equilíbrio em várias partes, como em 4 tentativas (como eu me lembro).
Suponha que o risco de 10% do saldo = 10 tentativas iguais?
calcular no depósito inicial o lote e ir, não recalcular mais
você pode
ps-ku no posto.
mas eu tenho testado essas exps... com um cálculo da equi
é uma morte lenta.
é melhor fazer como CALM
ele serrou o equilíbrio em várias partes, tentativas como (para 4 como eu me lembro)
Digamos que o risco é 10% do saldo = 10 tentativas iguaisFaça isso passar pela cabeça: você não tem que impor sua opinião a ninguém, muito menos à de qualquer outra pessoa. Por que você está falando de alguns **** que, dentre aqueles que lêem este tópico, talvez só você conheça. O homem tem sua própria mente, ele quer fazer o que quer. Por que dizer a ele como perder seu depósito mais rápido ou mais devagar? Isso não foi e não faz parte da pergunta.
Faça isso passar pela cabeça: você não tem que impor sua opinião a ninguém, muito menos à de qualquer outra pessoa. Por que você está falando de alguns **** que, dos que lêem este tópico, talvez só sejam conhecidos por você? O homem tem sua própria mente, ele quer fazer o que quer. Por que dizer a ele como perder seu depósito mais rápido ou mais devagar? Isso não foi e não faz parte da pergunta.
Eu não estou impondo nada, é apenas um exemplo livre.
Você perguntou - do patrimônio líquido podem ser contados lotes?
Eu disse que você pode, mas é uma chatice. Eu já tentei antes.
Em tais condições comerciais, é melhor calcular todos os lotes com o mínimo de alavancagem para não correr o risco de uma súbita escassez de fundos no momento mais inoportuno.
Neste caso 1k2
)))
Eu tenho um mínimo de 1k100
Eu tenho um mínimo de 1k100 e não tenho ameaça de redução.
)))
Minha pergunta era a seguinte: "A OrderCheck() ou OrderCalcMargin() leva em conta as características de alavancagem "especificada aproximadamente" na especificação?
Para que tipos de características você tem estatísticas acumuladas para refleti-las no valor calculado da OrderCalcMargin()? Deixe-me lembrá-lo destes tipos de recursos: A alavancagem depende de
1. O símbolo
2. Sua filiação à Polônia
3. Taxa de câmbio do símbolo
4. O período de tempo atual - se ele está em um dos períodos de notícias
5. Hora atual - atingiu em uma sexta-feira à noite
Ou não é? Em vez de coletar estatísticas, você reduz a possível alavancagem ao valor mínimo (na figura da 1ª mensagem, é 1:2 para BTCUSD, 1:25 para USDBUR) e é só isso?
P.S. Sua opinião sobre as ameaças para diminuir a alavancagem pode mudar se você analisar a diretiva da ESMA do regulador europeu que entrará em vigor neste verão. Por exemplo, aqui https://ru.forexmagnates.com/hochesh-torgovat-kak-ranshe-stan-profi/:
"Como lembrete, os corretores forex e CFD só podem operar normalmente dentro da União Européia até 1 de agosto de 2018. Depois disso, eles terão que se adaptar a condições substancialmente mais estritas. Nomeadamente, os corretores de varejo poderão oferecer negociação com uma alavancagem máxima de 1:30 nos principais pares de moedas, 1:20 nos não-maiores, 1:10 nas commodities e índices não-maiores, 1:5 nas ações e apenas 1:2 nos instrumentos de moedas criptográficas".
Falta menos de um mês. Só para lembrar, há muitos CDs registrados no Chipre e agora faz parte da União Européia, a diretiva ESMA se aplica a ele.
Minha pergunta era: "A OrderCheck() ou OrderCalcMargin() leva em conta características de alavancagem que são 'especificadas aproximadamente' na especificação".
Para que tipos de características você tem estatísticas acumuladas para refleti-las no valor calculado da OrderCalcMargin()? Deixe-me lembrá-lo destes tipos de recursos: A alavancagem depende de
1. O símbolo
2. Sua filiação à Polônia
3. Taxa de câmbio do símbolo
4. O período de tempo atual - se ele está em um dos períodos de notícias
5. Hora atual - atingiu em uma sexta-feira à noite
Ou não é? Em vez de coletar estatísticas, você reduz a possível alavancagem ao valor mínimo (na figura do primeiro post é 1:2 para BTCUSD, 1:25 para USDBUR) e é isso?
P.S. Sua opinião sobre as ameaças para diminuir a alavancagem pode mudar se você olhar através da diretiva ESMA do regulador europeu, que entra em vigor neste verão. Por exemplo, aqui https://ru.forexmagnates.com/hochesh-torgovat-kak-ranshe-stan-profi/:
Como lembrete, os corretores forex e CFD podem operar na União Européia no modo normal apenas até 1º de agosto de 2018. Depois disso, eles terão que se adaptar a condições significativamente mais estritas. Nomeadamente, os corretores de varejo poderão oferecer negociação com uma alavancagem máxima de 1:30 nos principais pares de moedas, 1:20 nos não-maiores, 1:10 nas commodities e índices não-maiores, 1:5 nas ações e apenas 1:2 nos instrumentos de moedas criptográficas.
As regras e condições comerciais são todas explicitadas, mas são aplicadas de forma diferente, ou melhor, nem sempre
Nem sempre é aplicado.
As empresas de corretagem e corretores não são discutidas aqui pelas regras deste fórum.
Portanto, você escolheu, cabe a você, adaptar-se.
Seu caso é um de muito poucos.
Vamos esperar pelo dia 1º de agosto.
Talvez sim, então eu escreverei o código e o postarei.
O problema não será nem mesmo o que você escreve, mas o momento de alavancar a mudança.
No passado, não podíamos pegá-lo sem reiniciar o terminal.
Agora - não sei, ainda não verifiquei.
As regras e condições comerciais dizem tudo isso, mas é aplicado de forma diferente, ou melhor, nem sempre
Quem tem o que
Não discutimos empresas de corretagem e corretores de acordo com as regras do fórum.
Então - você escolheu, é o seu negócio e você tem que se ajustar.
Seu caso é um de muito poucos
Vamos esperar pelo dia 1º de agosto.
Talvez acerte, então eu escreverei o código e o afixarei.
O problema não será nem mesmo o que você escreve, ele estará pegando o momento de alavancar a mudança.
Eu não poderia pegá-lo antes sem reiniciar o terminal.
Agora não sei, ainda não verifiquei.
Bem, pelo menos alguma coisa. Eu entendi corretamente que você não pode encontrar outra maneira de captar mudanças de alavancagem além de reiniciar o terminal? OrderCalcMargin() não capta estas mudanças, você diz? Essa é exatamente a informação que eu estava procurando. Verdadeiro, pertencente ao "agora", e aqui, infelizmente, permanece a incerteza.
A diferença entre 1:20 e a habitual 1:100 é importante para muitos. E nenhum código novo servirá, uma vez que a OrderCalcMargin() não captura mudanças de alavancagem, como você diz. Precisamos modificar a própria função OrderCalcMargin().
E o que dirá o desenvolvedor?
Bem, isso é alguma coisa. Corrija-me se entendi que você não conseguiu encontrar outra maneira de pegar a mudança de alavancagem, exceto recarregando o terminal. OrderCalcMargin() não capta estas mudanças, você diz?
Na verdade, não.
Eu tinha alavancagem e margem comparada em cada tick com o anterior, já que a alavancagem flutuava muito, dependendo da volatilidade.
Isto foi há 3 anos.
O comércio estava ativo e eu tinha que monitorar constantemente estes parâmetros.
Mais tarde eu abandonei a alavancagem (veja acima a razão), e acompanhei apenas as mudanças das condições de margem, múltiplos de alavancagem.
Este método provou ser eficaz.
Infelizmente, o código não sobreviveu, mas vou manter minha promessa.
Portanto, voltemos ao comando:
OrderCalcMargin(ORDER_TYPE_SELLL,_Symbol,1,BID,Mgn)
vamos memorizar no anterior
prevMgn=Mgn
e antes disso, vamos comparar
if(prevMgn/Mgn>1.1 || prevMgn/Mgn<1.1)
e o desejado está no bolso...
é hora de recalcular o ombroNa verdade, não.
Eu tinha alavancagem e margem comparada em cada tick com o anterior, já que a alavancagem flutuava muito, dependendo da volatilidade.
Isto foi há 3 anos.
O comércio estava ativo e eu tinha que monitorar constantemente estes parâmetros.
Mais tarde eu abandonei a alavancagem (veja acima a razão), e acompanhei apenas mudanças nas condições de margem, múltiplo de alavancagem.
Este método provou ser eficaz.
Infelizmente, o código não sobreviveu, mas vou manter minha promessa.
Portanto, voltemos ao comando:
OrderCalcMargin(ORDER_TYPE_SELLL,_Symbol,1,BID,Mgn)
vamos memorizar no anterior
prevMgn=Mgn
e antes disso, vamos comparar
if(prevMgn/Mgn>1.1 || prevMgn/Mgn<1.1)
E o desejado está no meu bolso...
é hora de recalcular o ombroVocê percebe que não se trata do código, mas sim de todos que podem recalcular. Mas você acrescentou volatilidade à lista de características, cujo impacto você de fato identificou. E se você for mais longe na floresta, você irá reunir cada vez mais lenha. Como levar isso em conta? O caso parece bastante desesperado...