Supponiamo che il secondo ordine di prezzo più alto vada per primo, è ricordato in prezzo_max, poi il primo, sostituito da prezzo_max, il secondo ordine è perso,
Si scopre che per evitare la ridondanza nel 99% dei casi si deve ancora scrivere tutto il codice a mano...
Beh, sto parlando di un equilibrio adeguato, e non si può evitare del tutto la ridondanza nel codice TRANSFORM. Mi sono fermato su una tale matrioska di 3 strutture
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;
È compilato durante un passaggio, è aggiornato quando il bot fa una transazione o il numero di ordini cambia. La ridondanza è al limite qui, penso. È sufficiente per me nel 90% dei casi ma non risolve il tuo problema; hai bisogno di una funzione separata
Dmitry Fedoseev: Supponiamo che il secondo ordine di prezzo più alto vada per primo, è memorizzato in price_max, poi il primo ordine è sovrascritto da price_max e il secondo ordine è perso,
no, non perdiamo il secondo ordine; l'ordine massimo è scritto prima
if(op>price_max) // Самый верхний ордер
{
price_max=op;
m_tick_upper=tc;
}
Se il secondo ordine è superiore, viene sovrascritto se è inferiore, allora la seconda condizione funziona
Beh, sto parlando di un equilibrio adeguato, e non si può evitare del tutto la ridondanza nel codice TRANSFORMAL. Ho stabilito una tale matrice di 3 strutture
Viene compilato durante un passaggio, aggiornato quando il bot fa un affare o il numero di ordini cambia. La ridondanza qui è troppo per me nel 90% dei casi ma non risolve il tuo problema; hai bisogno di una funzione separata
Quindi, si mettono due strutture in una terza ...
Il tuo metodo di riempire tutte le strutture è interessante...
Non c'è un modo più veloce. Se vuoi una maggiore velocità, devi pensare all'intero algoritmo dell'EA, forse puoi liberarti della necessità di cercare due bassi, due alti su ogni tick.
Devo ammettere che il tuo metodo di ricerca degli ordini è più stabile del mio in alcuni casi, ora sto facendo dei test e a seconda della posizione di apertura dell'ordine il tuo metodo funziona senza errori... Il mio metodo non funziona correttamente in alcuni casi...
Vladimir Pastushak: Devo ammettere che il tuo metodo di ricerca degli ordini è più stabile del mio in alcuni casi, ora sto facendo dei test e a seconda della posizione di apertura dell'ordine il tuo metodo funziona senza errori... Il mio metodo non funziona correttamente in alcuni casi...
Ne ho scritto ieri. Dipende da quale ordine è stato aperto.
Non sono OTK:) Prova su ordini nel tester o su un conto demo.
Cos'è il QA?
Si scopre che per evitare la ridondanza nel 99% dei casi si deve ancora scrivere tutto il codice a mano...
Beh, sto parlando di un equilibrio adeguato, e non si può evitare del tutto la ridondanza nel codice TRANSFORM. Mi sono fermato su una tale matrioska di 3 strutture
È compilato durante un passaggio, è aggiornato quando il bot fa una transazione o il numero di ordini cambia. La ridondanza è al limite qui, penso. È sufficiente per me nel 90% dei casi ma non risolve il tuo problema; hai bisogno di una funzione separata
Supponiamo che il secondo ordine di prezzo più alto vada per primo, è memorizzato in price_max, poi il primo ordine è sovrascritto da price_max e il secondo ordine è perso,
no, non perdiamo il secondo ordine; l'ordine massimo è scritto prima
Se il secondo ordine è superiore, viene sovrascritto se è inferiore, allora la seconda condizione funziona
il biglietto viene controllato, se non è il massimo ma il massimo, allora è il massimo prima del massimo.
Beh, sto parlando di un equilibrio adeguato, e non si può evitare del tutto la ridondanza nel codice TRANSFORMAL. Ho stabilito una tale matrice di 3 strutture
Viene compilato durante un passaggio, aggiornato quando il bot fa un affare o il numero di ordini cambia. La ridondanza qui è troppo per me nel 90% dei casi ma non risolve il tuo problema; hai bisogno di una funzione separata
Quindi, si mettono due strutture in una terza ...
Il tuo metodo di riempire tutte le strutture è interessante...
Non c'è un modo più veloce. Se vuoi una maggiore velocità, devi pensare all'intero algoritmo dell'EA, forse puoi liberarti della necessità di cercare due bassi, due alti su ogni tick.
Devo ammettere che il tuo metodo di ricerca degli ordini è più stabile del mio in alcuni casi, ora sto facendo dei test e a seconda della posizione di apertura dell'ordine il tuo metodo funziona senza errori... Il mio metodo non funziona correttamente in alcuni casi...
Ne ho scritto ieri. Dipende da quale ordine è stato aperto.
Ne ho scritto ieri. Dipende dall'ordine in cui l'hai aperto.