오류, 버그, 질문 - 페이지 1861

새 코멘트
 

또 다른 질문 - 플래그가 없는 것이 정상입니까? 빌드 1585

알파리


fxopen



FxOpen 알파리 MQ
COPY_TICKS_INFO
 입찰 및/또는 요청		 93016 83916 79292
COPY_TICKS_TRADE
 마지막 및 볼륨		 271061 0 102924
COPY_TICKS_ALL
 모든 진드기		 364077 426568 182216

모든 곳에서 COPY_TICKS_ALL = COPY_TICKS_INFO + COPY_TICKS_TRADE

그것은 alpar와 동일합니까?

 
kaus_bonus :

알파리

fxopen

오리발이 없습니다.
 
fxsaber :
오리발이 없습니다.


이것은 이해할 수 있지만 COPY_TICKS_ALL을 얻기 위해 추가되는 것은 무엇입니까?

COPY_TICKS_TRADE=0 이기 때문에

플래그가 누락된 기록의 틱은 알 수 없음 COPY_TICKS_TRADE ?

 
kaus_bonus :


이것은 이해할 수 있지만 COPY_TICKS_ALL을 얻기 위해 추가되는 것은 무엇입니까?

COPY_TICKS_TRADE=0 이기 때문에

플래그가 누락된 기록의 틱은 알 수 없음 COPY_TICKS_TRADE ?

이것이 중개인의 비뚤어진 손이라고 생각합니다.
 

HistoryDealGet* 및 HistoryOrderGet* 함수는 성능 면에서 매우 이상하게 작성되었습니다.

예를 들어 100K 개별 레코드에서 HistorySelect를 수행할 때. 그런 다음 HistoryDealGet 함수에는 기록 테이블의 레코드 번호가 아니라 티켓의 첫 번째 인수가 필요합니다. 표는 티켓이 아닌 시간별로 정렬됩니다. 따라서 실행할 때 HistoryDealGet 함수가 가장 먼저 하는 일은 매번 테이블을 통해 실행하고 적절한 티켓을 찾는 것입니다.


왜 그런 자원 낭비가 있습니까? 맨 처음 티켓과 맨 마지막 티켓이 다른 속도로 실행되는 것으로 나타났습니다. 그리고 마지막 거래의 모든 특성을 얻기 위해 HistoryDealGet 함수는 매번 전체 테이블을 통해 실행됩니다.


왜 제대로 하지 않습니까?

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


그리고 HFT 로봇을 테스트하는 방법은 현재 위치의 커미션 크기를 확인하기 위해 매번 HistorySelect를 통해 제동 기록으로 들어가야 하고 어떤 경우에도 HistorySelectByPosition을 통해 들어가야 하는 것은 아닙니다. 대기 중인 주문의 미끄러짐이 실적 쓰레기로 변하는 것을 보십시오!

 

테스터의 ACCOUNT_PROFIT는 넌센스를 보여줍니다.

바로 그 자리에서 포지션을 열고 닫는 어드바이저를 출시합니다.

 #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 ;          
  }
}

결과

 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는 0을 표시하지만 실제로는 -56.44입니다. 그 결과 자기자본, 드로다운 등이 잘못 평가된다.

PositionGetDouble( POSITION_PROFIT ) - 유사합니다.

 
fxsaber :

그리고 HFT 로봇을 테스트하는 방법은 현재 위치의 커미션 크기를 확인하기 위해 매번 HistorySelect를 통해 제동 기록으로 들어가야 하고 어떤 경우에도 HistorySelectByPosition을 통해 들어가야 하는 것은 아닙니다. 대기 중인 주문의 미끄러짐이 실적 쓰레기로 변하는 것을 보십시오!

HistorySelect는 요청된 시간 간격의 이진 검색을 통해 작동합니까? 저것들. O(N) 또는 O(log(N))?
 
fxsaber :
HistorySelect는 요청된 시간 간격의 이진 검색을 통해 작동합니까? 저것들. O(N) 또는 O(log(N))?
아니요. 이 경우 바이너리 검색은 적용되지 않습니다.
 
Slawa :
아니요. 이 경우 바이너리 검색은 적용되지 않습니다.
따라서 내부적으로 두 기록(주문 및 거래)이 시간별로 정렬됩니다. 우리는 완전히 최적화되지 않은 HistorySelectByPosition 이 아니라 HistorySelect에 대해 이야기하고 있습니다.
 
fxsaber :
따라서 내부적으로 두 기록(주문 및 거래)이 시간별로 정렬됩니다.

죄송합니다, 흥분했습니다.

예, 시간순으로 정렬됩니다. 시작 항목은 이진 검색으로 검색됩니다.

1...185418551856185718581859186018611862186318641865186618671868...3184
새 코멘트