Perguntas de um "boneco" - página 13

[[Excluído]]

stringo:

Na verdade, há até 8 bytes de informação dada à mensagem, que pode ser interpretada como desejada. Pode ser datado, duplo, 4 curtos, 8 char, ou 64 bits bit a bit.

Com quatro, 4 bytes de magia eram suficientes para codificar qualquer coisa, mas agora temos 8. Tudo o que precisa é de um desejo.

Eu sei, usei-a bastante bem em 4, e li o artigo (gostei muito da ideia).

Aqui não está claro apenas - Porque são especificados tipos diferentes em locais diferentes?

[Cron]

Por favor informe como pode fechar uma posição com TP e SL, se o preço estiver próximo do TP, e precisa de sair agora.

Envio uma ordem para abrir uma nova posição de igual volume. Na maioria dos casos funciona. Mas às vezes tenho uma situação em que uma posição tem tempo para fechar pela TP e em vez de fechar, obtenho uma nova posição no mercado... :(

Como posso indicar que a posição aberta se refere ao encerramento de uma posição existente, e se a posição principal já foi fechada, não para abrir uma nova?

Posso pensar em opções como "remover SL e TP antes do fecho ou esperar que o TP feche", mas não são soluções agradáveis. Não podemos realizar uma operação tão simples como FECHAR uma posição como a que realizámos no MT4?

[---]

Procurar em PositionClose na classe CTrade.
Tenho a certeza de que será o mesmo que o seu. Uma conclusão é inescapável - não há outra forma.

Mas eu apoio o seu pedido. Peço aos programadores que considerem esta variante.

Adicionar TRADE_ACTION_CLOSE tipo de operação - fecho de uma posição para um símbolo especificado no seu volume ao preço actual.

[Yedelkin]

stringo:

Na verdade, há até 8 bytes de informação dada à mensagem, que pode ser interpretada como desejada. Pode ser datado, duplo, 4 curtos, 8 char, ou 64 bits bit a bit.

Com quatro, 4 bytes de magia eram suficientes para codificar qualquer coisa, mas agora temos 8. Seria apenas uma ilusão.

Cerca de 8 bytes em comprimento e ulong ficou claro a partir da Referência. O que é preocupante é o uso inconsistente destes tipos no que diz respeito à magia.

Um exemplo simples: é aceitável atribuir pedido.magic=ULONG_MAX-1 ao enviar um pedido comercial. Porque é que o Manual de Referência diz que a função OrderGetInteger(ORDER_MAGIC) retorna apenas do tipo longo? Além disso, a magia também devolve tipo longo tanto para posições como para comércios.

Então, como foi originalmente concebido? Talvez devêssemos especificar paraestruturar MqlTradeRequest que a magia é de tipo longo, porque as funções HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. não se destinam a devolver valores inteiros superiores a LONG_MAX?

[[Excluído]]

Yedelkin:

Os 8 bytes de longo e ulong foram retirados do Manual de Referência. O uso inconsistente destes tipos em relação à magia é preocupante.

Um exemplo simples: ao enviar um pedido comercial, é aceitável atribuir request.magic=ULONG_MAX-1. Porque é que o Manual de Referência diz que a função OrderGetInteger(ORDER_MAGIC) retorna apenas do tipo longo? Além disso, a magia também devolve tipo longo tanto para posições como para comércios.

Então, como foi originalmente concebido? Talvez devêssemos especificar paraestruturar MqlTradeRequest que a magia é de tipo longo, porque as funções HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. não se destinam a devolver valores inteiros superiores a LONG_MAX?

Na realidade o magik é de tipo longo (isto pode ser facilmente verificado formando um magik negativo e um magik com um valor fora do intervalo de valores de tipo longo).

Para o verificar, podemos modificar ligeiramente o Consultor Especialista da Noite (não utiliza classes da biblioteca padrão).

Para tornar a experiência limpa, devemos alterar o tipo de parâmetro EA_Magic para prolongar e desenrolar o mágico da última ordem na história (se a ordem tiver sido estabelecida com sucesso).

[Yedelkin]

Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).

Se assim for, deve ser feita uma clarificação na descrição do elemento mágico da estruturaMqlTradeRequest, removendo a letra "u" do nome do tipo.

[[Excluído]]

Yedelkin:
Se assim for, é necessário clarificar a descrição do elemento mágico da estruturaMqlTradeRequest, removendo "u" do nome do tipo.

É uma boa ideia fazer também alterações na classe CTrade (se os criadores não quiserem limitar o valor mágico apenas a valores positivos).

[---]

stringo:

Na verdade, existe um total de 8 bytes de informação para a mensagem, que pode ser interpretada da forma que desejar. Pode ser datado, duplo, 4 curtos, 8 char, ou 64 bits bit a bit.

Com quatro, 4 bytes de magia eram suficientes para codificar qualquer coisa, mas agora temos 8. Seria apenas uma ilusão.

Na verdade, não são 64 mas apenas 63 bits (ou seja, 8 bytes incompletos). Seria de 8 bytes se utilizássemos toda a longa distância.

Mas infelizmente...

Por um lado, o ulong mágico é passado para a estrutura MqlTradeRequest. Isso significa que só podem ser definidos valores positivos.

Poroutro lado, as funções PositionGetInteger/OrderGetInteger devolvem o tipo longo. Isto significa que metade da gama ulong está cortada.

O que temos de facto são 63 bits em vez dos 64 bits acima descritos. Na verdade, não é tanto mau como um grande inconveniente para os princípios de verificação de encomendas.

Seria muito mais conveniente utilizar o mesmo sistema que no MT4 - permitir aos mágicos com um sinal. Uma vez que muitos sistemas comerciais se baseiam num princípio simples que utiliza o próprio símbolo de um mágico. Uma vez que é muito mais fácil dividir um sistema em dois e filtrar as suas encomendas usando a função habitual MathAbs( OrderMagicNumber() ).

[Renat Fatkhullin]

sergeev:

Na realidade não são 64 mas apenas 63 bits (ou seja, um 8 bytes incompleto). 8 bytes seria se toda a gama de longs fosse utilizada.

Está enganado.

64 bits são utilizados e cabe-lhe a si a forma como os utiliza. Long/ulong não faz diferença, tudo depende de como se interpreta esses 64 bits. Se quiser usar como um longo assinado - use-o, se quiser usá-lo como um ulong não assinado - não há problema. Se quiser utilizar outros tipos de dados nestes 64 bits, faça-o.

Foi exactamente sobre isto que Slava escreveu.

[Vladimir Gomonov]

sergeev:

Na realidade não são 64 mas apenas 63 bits (ou seja, um 8 bytes incompleto). 8 bytes seria se todo o longo alcance fosse utilizado.

Mas infelizmente...

Por um lado, o ulong mágico é passado para a estrutura MqlTradeRequest. Isso significa que só podem ser definidos valores positivos.

Poroutro lado, as funções PositionGetInteger/OrderGetInteger devolvem o tipo longo. Isto significa que metade da gama ulong está cortada.

No total, temos 63 bits em vez dos 64 acima descritos. Na verdade, não é tanto mau como um grande inconveniente para os princípios de verificação de encomendas.

Seria muito mais conveniente utilizar o mesmo sistema que no MT4 - permitir aos mágicos com um sinal. Uma vez que muitos sistemas comerciais se baseiam num princípio simples que utiliza o próprio símbolo de um mágico. Uma vez que é muito mais fácil dividir um sistema em dois e filtrar as suas encomendas usando a função habitual MathAbs( OrderMagicNumber() ).

Estou francamente intrigado. Vocês estão a exagerar em nada de mais. Absolutamente nada. Este problema não existe, apenas o inventou. Classificar as conversões de tipo até ao fim.

Espero que a peça abaixo o ajude. Copie-o num guião, compile-o, execute-o no terminal e depois pense muito bem. Boa sorte.

void OnStart()
  {
    Print("//------ ");

    int i_A = -100;
    uint ui_B = uint(-100);
    
    Print(i_A," ",uint(i_A));
    Print(int(ui_B)," ",ui_B);

    i_A = int(4294967196);
    ui_B = 4294967196;

    Print(i_A," ",uint(i_A));
    Print(int(ui_B)," ",ui_B);
//--
    long l_A = -100;
    ulong ul_B = ulong(-100);
    
    Print(l_A," ",ulong(l_A));
    Print(long(ul_B)," ",ul_B);
   
    l_A = long(18446744073709551516);
    ul_B = 18446744073709551516;
    
    Print(l_A," ",ulong(l_A));
    Print(long(ul_B)," ",ul_B);
  }