Suponha que a segunda ordem de preço mais alto vai primeiro, ela é lembrada em price_max, depois a primeira, substituída por price_max, a segunda ordem é perdida,
Acontece que para evitar redundância em 99% dos casos você ainda deve escrever todo o código à mão...
Bem, estou falando de um equilíbrio adequado, e você não pode evitar em absoluto a redundância no código TRANSFORM. Eu parei em uma matryoshka de 3 estruturas assim
struct ORDER {
double d_Price;
double d_Lot;
double d_Profit;
string s_Comment;
datetime t_Time;
int i_Ticket;
int i_Op_Type;
};
struct ORDERS_GROUP {
double d_Lots_Total; // сумма лотовdouble d_Profit_Total; // суммарная прибыльdouble d_BreakEven_Price; // уровень б/у
ORDER o_Lowest; // параметры нижнего ордера
ORDER o_Highest; // параметры верхнего ордера
ORDER o_Oldest; // параметры старейшего ордера
ORDER o_Newest; // параметры новейшего ордераint i_Orders_Total; // кол-во ордеров
};
struct ALL_ORDERS {
int i_Orders_Total; // кол-во ордеровdouble d_Lots_Total; // сумма лотовdouble d_Profit_Total; // суммарная прибыльdouble d_BreakEven_Price; // уровень б/уdouble d_One_Point_Price; // прибыль одного пунктаdatetime t_Data_Collected; // время последнего обновления данныхbool b_Changed; // была операция после последнего обновления данных?
ORDERS_GROUP o_Buy; // сводка данных ордеров Buy
ORDERS_GROUP o_Sell; // сводка данных ордеров Sell
ORDERS_GROUP o_Buy_Stop; // сводка данных ордеров BuyStop
ORDERS_GROUP o_Sell_Stop; // сводка данных ордеров SellStop
ORDERS_GROUP o_Buy_Limit; // сводка данных ордеров BuyLimit
ORDERS_GROUP o_Sell_Limit; // сводка данных ордеров SellLimit
ORDERS_GROUP o_Market; // сводка данных рыночных ордеров
ORDERS_GROUP o_Pendings; // сводка данных отложенных ордеров
};
ALL_ORDERS go_Orders;
É preenchido durante uma passagem, é atualizado quando o bot faz uma transação ou o número de pedidos muda. A redundância está no limite aqui, eu acho. É suficiente para mim em 90% dos casos, mas não resolve seu problema; você precisa de uma função separada
Dmitry Fedoseev: Suponha que a segunda ordem de preço mais alto vai primeiro, ela é armazenada em price_max, então a primeira ordem é sobrescrita por price_max e a segunda ordem é perdida,
não, não perdemos a segunda ordem; a ordem máxima é escrita primeiro
if(op>price_max) // Самый верхний ордер
{
price_max=op;
m_tick_upper=tc;
}
Se a segunda ordem é mais alta, ela é sobrescrita se for mais baixa, então a segunda condição funciona
Bem, estou falando de um equilíbrio adequado, e você não pode evitar a redundância no código TRANSFORMAL por completo. Eu me fixei em tal matriz de 3 estruturas
A redundância aqui é muito grande para mim em 90% dos casos, mas não resolve seu problema; você precisa de uma função separada.
Então, você coloca duas estruturas em uma terceira ...
Seu método de preenchimento de todas as estruturas é interessante ...
Não há maneira mais rápida. Se você quiser mais rápido, você precisa pensar em todo o algoritmo EA, talvez você possa se livrar da necessidade de procurar dois baixos, dois altos em cada carrapato.
Devo admitir que seu método de busca de pedidos é mais estável que o meu em alguns casos, agora estou fazendo testes e, dependendo da posição de abertura do pedido, seu método funciona sem erros... Meu método não funciona corretamente em alguns casos...
Vladimir Pastushak: Devo admitir que seu método de encontrar pedidos é mais estável que o meu em alguns casos, agora estou fazendo testes e, dependendo da posição de abertura do pedido, seu método funciona sem erros... Meu método não funciona corretamente em alguns casos...
Eu não sou OTK:) Teste em pedidos no testador ou em uma conta de demonstração.
O que é QA ?
Acontece que para evitar redundância em 99% dos casos você ainda deve escrever todo o código à mão...
Bem, estou falando de um equilíbrio adequado, e você não pode evitar em absoluto a redundância no código TRANSFORM. Eu parei em uma matryoshka de 3 estruturas assim
É preenchido durante uma passagem, é atualizado quando o bot faz uma transação ou o número de pedidos muda. A redundância está no limite aqui, eu acho. É suficiente para mim em 90% dos casos, mas não resolve seu problema; você precisa de uma função separada
Suponha que a segunda ordem de preço mais alto vai primeiro, ela é armazenada em price_max, então a primeira ordem é sobrescrita por price_max e a segunda ordem é perdida,
não, não perdemos a segunda ordem; a ordem máxima é escrita primeiro
Se a segunda ordem é mais alta, ela é sobrescrita se for mais baixa, então a segunda condição funciona
o bilhete é verificado, se não for o máximo, mas o bilhete superior, então ele é o topo antes do máximo.
Bem, estou falando de um equilíbrio adequado, e você não pode evitar a redundância no código TRANSFORMAL por completo. Eu me fixei em tal matriz de 3 estruturas
A redundância aqui é muito grande para mim em 90% dos casos, mas não resolve seu problema; você precisa de uma função separada.
Então, você coloca duas estruturas em uma terceira ...
Seu método de preenchimento de todas as estruturas é interessante ...
Não há maneira mais rápida. Se você quiser mais rápido, você precisa pensar em todo o algoritmo EA, talvez você possa se livrar da necessidade de procurar dois baixos, dois altos em cada carrapato.
Devo admitir que seu método de encontrar pedidos é mais estável que o meu em alguns casos, agora estou fazendo testes e, dependendo da posição de abertura do pedido, seu método funciona sem erros... Meu método não funciona corretamente em alguns casos...
Eu escrevi sobre isso ontem. Depende de qual ordem foi aberta.
Eu escrevi sobre isso ontem. Depende da ordem em que você a abriu.