Errors, bugs, questions - page 1861

New comment
 

another question - is it normal that there are no flags? build 1585

Alpari


fxopen



FxOpenAlpariMQ
COPY_TICKS_INFO
Bid and/or Ask		930168391679292
COPY_TICKS_TRADE
Last and Volume		2710610102924
COPY_TICKS_ALL
all ticks		364077426568182216

if everywhereCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

then what does it equal at Alpari?

 
kaus_bonus:

Alpari

fxopen

They don't have flippers.
 
fxsaber:
They have no flags.


it is clear, but then what is added to getCOPY_TICKS_ALL?

because they haveCOPY_TICKS_TRADE=0

and the ticks in the story with the missing flags are the unknownCOPY_TICKS_TRADE ?

 
kaus_bonus:


it is clear, but then what is added to getCOPY_TICKS_ALL?

because they haveCOPY_TICKS_TRADE=0

and the ticks in the history with missing flags is unknownCOPY_TICKS_TRADE ?

I think it is the crooked hands of the brokers.
 

HistoryDealGet* and HistoryOrderGet*-functions are written very strangely, in terms of performance.

When I make HistorySelect, for example, for 100K individual records. The HistoryDealGet-function shall require as the first argument not the number of records in the history table, and a ticket. And the table is sorted by time, and not by ticket. Therefore, the first thing the HistoryDealGet function does, each time it executes, is to run through the table and look for a matching ticket.


Why such a waste of resources! It turns out that the very first ticket and the most recent one will be executed at different speeds. And to get all characteristics of the last deal, HistoryDealGet-functions will run through the whole table each time.


Why not make it normal?

long HistoryDealGetInteger( const int index, const ENUM_ORDER_PROPERTY_INTEGER  property_id ); // номер сделки, а не тикет


And how can HFT-robot be tested, if in order to get the amount of commission of the current position, we have to climb into the slow history every time through HistorySelect, and in no case through HistorySelectByPosition? The slippage of the pending order turns into a performance trash!

 

ACCOUNT_PROFIT in the tester shows nonsense.

Now we run an Expert Advisor that opens and closes the position immediately

#include <MT4Orders.mqh>

#define  PRINT(A) Print(#A + " = " + (string)(A));

void OnTick()
{  
  static bool FirstRun = true;

  if (FirstRun && OrderSelect(OrderSend(_Symbol, OP_BUY, 1, 0, 0, 0, 0), SELECT_BY_TICKET))
  {
    PRINT(AccountInfoDouble(ACCOUNT_PROFIT))
    
    if (OrderClose(OrderTicket(), OrderLots(), 0, 0) && OrderSelect(OrdersHistoryTotal() - 1, SELECT_BY_POS, MODE_HISTORY))
      OrderPrint();
    
    FirstRun = false;          
  }
}

The result is

2017.04.19 23:24:50.317 RTS-6.17,M1 (MetaQuotes-Demo): generating based on real ticks
2017.04.19 23:24:50.317 RTS-6.17,M1: testing of Experts\fxsaber\Test2.ex5 from 2017.04.06 00:00 to 2017.04.08 00:00 started
2017.04.19 23:24:50.419 RTS-6.17 : real ticks begin from 2017.04.06 00:00:00
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal #2  buy 1.00 RTS-6.17 at 114250 done (based on order #2)
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal performed [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.419 2017.04.06 09:45:01   order performed buy 1.00 at 114250 [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   AccountInfoDouble(ACCOUNT_PROFIT) = 0.0
2017.04.19 23:24:50.421 2017.04.06 09:45:01   exchange sell 1.00 RTS-6.17 at 114200, close #2 (114200 / 114250)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal #3  sell 1.00 RTS-6.17 at 114200 done (based on order #3)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal performed [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   order performed sell 1.00 at 114200 [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   #3 2017.04.06 09:45:01 buy 1.00 RTS-6.17 114250 0 0 2017.04.06 09:45:01 114200 0.00 0.00 -56.44 0
2017.04.19 23:24:50.629 RTS-6.17,M1: 582089 ticks, 1573 bars generated. Environment synchronized in 0:00:00.063. Test passed in 0:00:00.421 (including ticks preprocessing 0:00:00.078).

ACCOUNT_PROFIT shows zero, but in fact it is -56.44. As a consequence, equity, drawdown, etc. are estimated incorrectly.

PositionGetDouble(POSITION_PROFIT) - same thing.

 
fxsaber:

And how can an HFT-robot be tested, if in order to know the commission size of the current position, you need to get into the history through HistorySelect and in no case through HistorySelectByPosition? To see the slippage of a pending order turns into a performance trash!

Does HistorySelect work through a binary search of the requested time interval or not? I.e. O(N) or O(log(N))?
 
fxsaber:
Does HistorySelect work through a binary search of the requested time interval or not? I.e. O(N) or O(log(N))?
No. The binary search is not applicable in this case
 
Slawa:
No. Binary search is not applicable in this case
So internally both stories (Orders and Deals) are sorted by time. We are talking about HistorySelect, and not about HistorySelectByPosition, which is not optimized at all.
 
fxsaber:
So internally both stories (Orders and Deals) are sorted by time.

I'm sorry, I got a little excited.

Yes, they are sorted by time. The initial record is searched with a binary search.

1...185418551856185718581859186018611862186318641865186618671868...3190
New comment