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
Seja como for.
if(a==0){expressão} significa que se a é 0 então é verdade, então execute {expressão}.
if(a=0){expressão} é equivalente a if(a){a=0;expressão} se a for verdade, {a=0;expressão}.
A segunda está errada, deveria ser escrita assim
se(a=x) { expressão } atribuir o valor de x à variável a, e se a não for 0 depois disso, então executar a expressão
se(a=0) { } após a optimização haverá apenas a=0
A segunda está errada. A forma correcta de a escrever é
se(a=x) { expressão } atribuir o valor de x à variável a, e se a não for 0 depois disso, executar a expressão
se(a=0) { } após a optimização haverá apenas a=0
Desculpe, isso é verdade, as expressões são executadas da esquerda para a direita.
É por isso que começamos com a tarefa, e depois verificamos a verdade.
Este é, grosso modo, o caso:
Este código não só calcula o volume máximo como também o enquadra exactamente nas limitações das definições do símbolo.Calcula-o mas esquece-se porque o calcula quando o insere:
O valor do lote por este ponto é calculado de modo a consumir toda a margem disponível com uma margem mínima.
Se este valor for aumentado em pelo menos um passo de volume, não haverá dinheiro suficiente para abrir uma posição.
Mas a segunda linha do código citado MAQUISA o valor do lote no caso da condição sob se cumprir, e pode aumentá-lo num valor muito maior do que o valor do passo de volume, porque na realidade há volume min = 0,1 e passo de volume = 0,01.
E neste código abaixo, pode ocorrer uma divisão por zero, contra a qual não existe protecção:
Se SymbolInfoDouble() devolver 0, é tudo. Os programas MQL5 terminam na divisão por 0, certo? Não pode regressar 0? As pessoas aqui queixam-se de que as funções informativas regressam muitas vezes a 0. Não se pode cair "não regressa a 0" porque, em primeiro lugar, pode, e em segundo lugar, a divisão por 0 é fatal.
Há algumas observações menores sobre a "precisão da entrada", mas não são realmente muito significativas, ou seja, não têm consequências tão graves, pode ignorá-las.
Antecipando possíveis argumentos de que o código é "aproximado", reparo: quantos utilizadores do produto são capazes de encontrar e reparar competentemente tais "maus lugares"?
Para eles, isto é "código dos criadores". Um exemplo a ter em conta.
Porque é que o botão "Next" não está activo quando todos os campos obrigatórios são preenchidos?
Porque é que o botão "Next" não está activo quando todos os campos obrigatórios são preenchidos?
Calcula, mas depois esquece para que estava a calcular:
Antecipando possíveis argumentos de que o código é "aproximado", gostaria de salientar: quantos utilizadores do produto podem corrigir correctamente tais "sítios maus"?O código era aproximado (copiado de duas peças), mas os seus comentários estão correctos.
Aqui está a versão corrigida:
E porquê session_index++; quando session_index=1 já é falso:
Não podemos saber com antecedência qual é o número de sessões por ferramenta. Por isso, consultamos cada sessão por número. Se for verdade
session_exist=SymbolInfoSessionQuote(symbol,day,session_index,start,finish);
estamos interessados no tempo do seu início e fim. Se formos enganados - é isso, não há sessão com este número.
Não podemos saber com antecedência qual é o número de sessões de um instrumento. Por conseguinte, solicitamos cada sessão por número. Se for verdade
analisamos o tempo do seu início e fim. Se formos enganados - é isso, não há sessão com este número.
A...... então porque é que tudo acaba na sexta-feira às 24:00 e na realidade às 23:00?