Perguntas de um "boneco" - página 176

[Yedelkin]

Karlson:

3Б. Encerramento parcial através da abertura de uma meia venda - OUT.

É pena :/ Acontece que pode haver vários ofícios na história com a propriedade OUT, enquanto a posição ainda existirá.

[Anatoli Kazharski]

Yedelkin:
Mau :/

Porquê mau? É simples, se bem o entendi. Se OUT e houver uma posição, houve uma redução no volume. Se OUT e sem posição, então a posição foi completamente fechada.

[Yedelkin]

tol64:
Porque é que é mau? Tudo é simples, se o entendi correctamente. Se houver uma posição e OUT, houve uma diminuição no volume. Se OUT e não houver nenhuma posição, então a posição foi completamente fechada.

O mau é isto. A sua abordagem"Se OUT e houver uma posição, houve uma redução no volume. Se não há OUT e não há posição, então a posição foi completamente fechada" tem uma característica que considero incómoda, nomeadamente, a necessidade de verificar adicionalmente a existência de informação sobre a posição na base de dados do terminal de cada vez.

Todos sabemos que a informação no terminal de base fica com um certo atraso em relação à situação real. Por conseguinte, não podemos excluir situações em que o resultado da verificação é"há uma posição e está OUT", mas de facto a posição foi encerrada. Por outras palavras, é possível obter informações inexactas e utilizá-las como base para a tomada de acções erradas. Ou será necessário inventar verificações adicionais, atrasos, ou o que for conveniente.

Mas pode passar sem todos estes truques. Em particular, sem verificar a disponibilidade de posição. Para tal, é suficiente deixar uma correspondência de um para um entre o fecho da posição e a propriedade DEAL_ENTRY_OUT (correspondência - como é agora apresentada no Manual), e alocar a redução do volume da posição numa propriedade separada da transacção. Então será suficiente encontrar na história (HistorySelectByPosition) um único negócio com propriedade DEAL_ENTRY_OUT, e ter a certeza de que a posição não é reduzida, mas exactamente fechada, e que em nenhuma circunstância pode ser invertida.

[Anatoli Kazharski]

Yedelkin:

O mau é isto. A sua abordagem"Se OUT e houver uma posição, houve uma redução no volume. Se não há OUT e não há posição, então a posição foi completamente fechada" tem uma característica que considero incómoda, nomeadamente, a necessidade de verificar adicionalmente a informação sobre a posição na base de dados do terminal de cada vez.

Todos sabemos que a informação no terminal de base fica com um certo atraso em relação à situação real. Por conseguinte, não podemos excluir situações em que o resultado da verificação é"há uma posição e está OUT", mas na realidade a posição foi totalmente fechada. Por outras palavras, é possível obter informações inexactas e utilizá-las como base para a tomada de acções erradas. Ou será necessário inventar verificações adicionais, atrasos, ou o que for conveniente.

Mas pode passar sem todos estes truques. Em particular, sem verificar a disponibilidade de posições. Para tal, é suficiente deixar uma correspondência de um para um entre o fecho da posição e a propriedade DEAL_ENTRY_OUT (correspondência - como é agora apresentada no Manual), e alocar a redução do volume da posição numa propriedade separada da transacção. Então será suficiente encontrar na história (HistorySelectByPosition) um único negócio com propriedade DEAL_ENTRY_OUT e saber com certeza que a posição não é reduzida, mas exactamente fechada, e que em nenhuma circunstância pode ser invertida.

Na OnTrade(), recebemos a resposta do servidor. Ou seja, se verificarmos o evento no OnTrade(), já saberemos ao certo se existe ou não uma posição. Embora possamos fornecer opções padrão tais como DEAL_ENTRY_FULLOUT (fechamento completo) ouDEAL_ENTRY_PARTOUT (fechamento parcial) para tornar tudo perfeitamente elegante.)))

Entretanto, pode fazer funções separadas, para que não tenha de introduzir "verificações incómodas" de cada vez.

[Yedelkin]

tol64:

Embora pudesse fazer opções padrão como DEAL_ENTRY_FULLOUT ouDEAL_ENTRY_PARTOUT para tornar tudo perfeitamente elegante.)))

É disso que se trata. Nem sequer teremos de fazer verificações adicionais no OnTrade, o que parecerá demasiado complicado em comparação com a solução proposta (FULLOUT / PARTOUT).

[Anatoli Kazharski]

Yedelkin:
Essa é a questão... Não teria sequer de fazer verificações extra na OnTrade, o que continuaria a parecer complicado quando comparado com a solução proposta (FULLOUT / PARTOUT).

Tente fazer uma proposta ao Service Desk. Talvez eles o considerem e um dia o implementem.

[Yedelkin]

tol64:
Tente fazer uma proposta ao Service Desk. Talvez eles o considerem e um dia o implementem.

Eu já fiz :) Como erro de linguagem ...Uau, demorei uma hora a compor.

[Anatoli Kazharski]

Yedelkin:
Eu já fiz :) Como um deslize da língua... Uau, demorei uma hora a compor.

Ainda não se pode chamar a isto um erro. Mas o que se pode fazer agora que já foi enviado. ))

[Yedelkin]

tol64:
Ainda não se pode chamar a isto um erro. Mas o que se pode fazer agora que foi enviado. ))

Bem, é aqui que as categorias de avaliação entram um pouco em jogo :) Tentei justificar a categoria Erros :)

[Валерий]

Yedelkin:

Sim, cada período corresponde a um determinado valor. Alguém o publicou no fórum há alguns anos atrás. Pode descobrir por si próprio, executando uma linha como a que se segue:

O guião imprimirá os valores ENUM_TIMEFRAMES para todos os períodos no sistema decimal:

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+