Erros, bugs, perguntas - página 444

[[Excluído]]

Interesting:
As sessões de negociação e de cotação não vão ajudar a resolver o problema?

Infelizmente, não. De acordo com a especificação do contrato, a sessão de cotação começa às 00:00:00 de segunda-feira.
Na verdade, aqui Rosh dá a resposta que o início de uma sessão de cotação não garante a disponibilidade de citações na mesma. O que, em princípio, é compreensível.

Até agora, estou a usar uma "muleta" sob a forma da seguinte verificação:

input int TTL = 10; // Время "жизни" котировки
...
void Trade() {
  ...
  if (TimeCurrent() - SymbolInfoInteger(Instrumet, SYMBOL_TIME) > TTL) return;
  ...
  // Далее отправка торгового приказа на сервер.
}

Ficaria grato se alguém pudesse partilhar uma solução mais elegante (todos os utilizadores com múltiplas moedas devem ter-se deparado com isto).

P.S.
Konstantin Gruzdev oferece uma variante elegante no seu artigo Implementing the multicurrency mode in MetaTrader 5.
Mas esta variante não irá satisfazer os requisitos para o Campeonato.

[Vladimir Gomonov]

voix_kas:

Yikes... que atingiu 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.

:)

[Aleksey Lebedev]

voix_kas:

OrderCheck não ajuda?

[Aleksey Lebedev]

Referência:

Функцию Sleep() нельзя вызывать из пользовательских индикаторов, так как индикаторы выполняются в интерфейсном потоке и не должны его тормозить.

É realmente, realmente impossível, ou se realmente quiser, pode, mas com cuidado? :)

Problema em aceder aos dados de outro símbolo a partir do indicador.

se não houver carrapatos)

[[Excluído]]

Swan:
OrderCheck não ajuda?

Não. Eu escrevo uma linha antes do ofício:

if (!OrderCheck(TradeRequest, TradeCheckResult) || (TradeCheckResult.retcode != TRADE_RETCODE_DONE)) return;

Ainda há um erro no registo. :(

[Andrey Khatimlianskii]

E a normalização de lotes?

Rapazes, porquê teorizar?

Uma situação em que o incremento do lote será maior do que o lote mínimo é absurda. Bem, imagine: min = 0,1, passo = 1,0. Então, apenas os lotes 1.1, 2.1, 3.1, ... são permitidos? Isto é um disparate.

Se estiver a exercer aritmética e programação, então as suas opções vencerão. Mas se estamos a falar de programação aplicada (no sentido de negociação), então em lot_step > lot_min devemos terminar o programa com um erro crítico e mudar urgentemente o corretor, porque ele não tem dinheiro suficiente mesmo para o salário de uma pessoa que normalmente configuraria o servidor).

Tudo tem de ser moderado. A minha variante tem estado a trabalhar em reais há mais de 5 anos, com diferentes corretores, tipos de contas, instrumentos - nunca teve um erro.

[[Excluído]]

komposter
Porque é absurdo? Tomemos um exemplo simples: min_lot = 1,0, min_step = 0,3. Os requisitos satisfazem o princípio de "nenhum disparate" (min_lot >= lot_step). :)
Passa-se 1,3 volume de lotes para a função de normalização. Dela se devolve 1,2 lotes.
A versão melhorada irá retornar 1.3. Os seus passos são "correctos": a partir do lote mínimo, não a partir do zero.

Outra questão é a presença de etapas "na vida" que não"1.0, 0.1, 0.01, etc.".
Aqui, parece-me que o custo da questão (perda de desempenho) é insignificante em comparação com a solução de um possível erro hipotético. IMHO.
Afinal, é mais correcto contar dessa forma: passos a partir do lote mínimo, não a partir do zero.

[Гребенев Вячеслав]

Existe algum código pronto algures que possa comprar o máximo número possível de lotes ao símbolo e preço actuais por um determinado montante (por exemplo $1234,56 é o único parâmetro de entrada)? No interior devem existir todos os tipos de verificações para volumes máximos, mínimos, normalização, contabilidade de alavancagem, suficiência de fundos, etc., etc. O principal é que o código deve fazer uma compra e não me incomodar com o facto de não haver dinheiro (comprar tanto quanto há), que algum cheque falhou (obtê-lo), que uma encomenda é feita, mas não houve compra (morrer, mas não voltar sem ele), etc. Compreendo que algures nas aulas como a CTrade isto é. Mas não é assim tão fácil copiar algo a partir daí. Quero lidar com o meu próprio algoritmo, não com a linguagem da MQL5.

[Aleksey Lebedev]

voix_kas:

Não. Eu escrevo uma linha antes de negociar:

Ainda há um erro nos registos. :(

Olhados, nas contas do campeonato, todos os instrumentos são negociados ao mesmo tempo. Registar)

TradeCheckResult.retcode != TRADE_RETCODE_DONE

Não tenho tanta certeza quanto a esta condição...

Não sei se esta condição é ou não correcta:

if(preço actual == 0.0) retorno;

[Andrey Khatimlianskii]

voix_kas:

komposter
Porque é absurdo? Vamos dar um exemplo simples: lote mínimo = 1,0, passo mínimo = 0,3. Os requisitos satisfazem o princípio de "nenhum disparate" (min_lot >= lot_step). :)
Passa-se 1,3 volume de lotes para a função de normalização. A partir dele 1,2 lotes são devolvidos a si.
A versão melhorada irá retornar 1.3. Os seus passos são "correctos": a partir do lote mínimo, não a partir do zero.

Outra questão é a presença de etapas "na vida" que não"1.0, 0.1, 0.01, etc.".
Aqui, parece-me, o custo da questão (perda de desempenho) é insignificante em comparação com a solução para um possível erro hipotético. IMHO.
Afinal, é apenas mais correcto contar desta forma: passos a partir do lote mínimo, não a partir do zero.

"lote mínimo = 1,0, passo mínimo = 0,3" também é absurdo. Os passos devem ser um múltiplo do lote mínimo.

Já expressei a minha opinião - num concurso de matemática e programação, a variante de subtracção min_lot ganhará, não é necessária para o comércio real.

Não vejo o assunto para mais discussão, cada um fez o seu próprio caminho ;)