동일한 기호에 대해 여러 Expert Advisors를 동시에 거래하는 사람들에게는 순 제출이 골칫거리입니다. 두 전문가 고문이 모두 헤지 상태에 있는 상황을 해결하려면 순 포지션이 없다고 해서 실제로 시장에 있지 않다는 의미가 아니라 복잡한 코드가 생성된다는 점을 이해해야 합니다. 한 가지 솔루션은 전체 위치에 대한 각 전문가의 기여도를 계산하는 것입니다. 이렇게 하려면 전체 이력을 분석하고 각 고유 마술사가 속한 계약 수를 계산해야 합니다. 숫자가 0.0이면 - Expert Advisor는 시장에 없는 것이고, 음수이면 - Expert Advisor는 숏 포지션을 유지하고, 양수이면 - 롱 포지션을 취합니다. 사실, CHashMap을 사용하면 이 작업을 수행하는 것이 매우 쉽기 때문에 모든 거래를 볼륨을 합산하여 마법 주문으로 분해하기에 충분합니다. 아래에 매우 단순화된 코드(프로토타입)를 게시했습니다.
//+------------------------------------------------------------------+//| NettoByMagic.mq5 |//| Copyright 2017, MetaQuotes Software Corp. |//| http://www.mql5.com |//+------------------------------------------------------------------+#property copyright"Copyright 2017, MetaQuotes Software Corp."#property link"http://www.mql5.com"#property version"1.00"#include <Generic\HashMapGen.mqh>
CHashMap< ulong , double > PositionsByMagic;
int prev_deals = 0 ;
//+------------------------------------------------------------------+//| Добавляет новый объем и его меджик |//+------------------------------------------------------------------+void AddVolume( ulong magic, double volume)
{
double cur_volume = 0.0 ;
if (PositionsByMagic.TryGetValue(magic, cur_volume))
PositionsByMagic.TrySetValue(magic, cur_volume+volume);
else
PositionsByMagic.Add(magic, volume);
}
//+------------------------------------------------------------------+//| Добавляет новые сделки в словарь |//+------------------------------------------------------------------+void ParseDeals()
{
HistorySelect ( 0 , TimeCurrent ());
for ( int i = prev_deals; i < HistoryDealsTotal (); i++)
{
ulong ticket = HistoryDealGetTicket (i);
if ( HistoryDealGetString (ticket, DEAL_SYMBOL )!= Symbol ())
continue ;
ENUM_DEAL_TYPE deal_type = ( ENUM_DEAL_TYPE ) HistoryDealGetInteger (ticket, DEAL_TYPE );
double volume = 0.0 ;
if (deal_type == DEAL_TYPE_BUY )
volume = HistoryDealGetDouble (ticket, DEAL_VOLUME );
elseif (deal_type == DEAL_TYPE_SELL )
volume = HistoryDealGetDouble (ticket, DEAL_VOLUME )*(- 1 );
elsecontinue ;
ulong magic = HistoryDealGetInteger (ticket, DEAL_MAGIC );
AddVolume(magic, volume);
}
prev_deals = HistoryDealsTotal();
}
//+------------------------------------------------------------------+//| Script program start function |//+------------------------------------------------------------------+voidOnTick ()
{
ParseDeals();
for ( int i = 0 , k = 0 ; i < PositionsByMagic.Count(); i++)
{
ulong magic = PositionsByMagic.GetKeyAt(i);
double valume = PositionsByMagic.GetValueAt(i);
if (k == 10 )
break ;
}
}
//+------------------------------------------------------------------+
주목! 단순화를 위해 코드는 현재 기호의 순 부피만 계산합니다. 또한 현재 구현된 CHashMap에는 반복자가 포함되어 있지 않아 급하게 이러한 반복자를 만들었습니다. 수정된 CHashMap은 첨부 파일에 표시됩니다.
흥미로운. 그리고 그런 질문. 현재 구현이 마음에 들지 않아 수정했습니다. 물론 삐뚤삐뚤합니다. 원본 성경을 얻는 방법?
다음은 1702년부터입니다.
다음은 1702년부터입니다.
고맙습니다! 개발자에게 질문을 하겠습니다. 왜냐하면 난 아직도 그 교정기야...
예 2: 순 계정에서 여러 Expert Advisors 거래
동일한 기호에 대해 여러 Expert Advisors를 동시에 거래하는 사람들에게는 순 제출이 골칫거리입니다. 두 전문가 고문이 모두 헤지 상태에 있는 상황을 해결하려면 순 포지션이 없다고 해서 실제로 시장에 있지 않다는 의미가 아니라 복잡한 코드가 생성된다는 점을 이해해야 합니다. 한 가지 솔루션은 전체 위치에 대한 각 전문가의 기여도를 계산하는 것입니다. 이렇게 하려면 전체 이력을 분석하고 각 고유 마술사가 속한 계약 수를 계산해야 합니다. 숫자가 0.0이면 - Expert Advisor는 시장에 없는 것이고, 음수이면 - Expert Advisor는 숏 포지션을 유지하고, 양수이면 - 롱 포지션을 취합니다. 사실, CHashMap을 사용하면 이 작업을 수행하는 것이 매우 쉽기 때문에 모든 거래를 볼륨을 합산하여 마법 주문으로 분해하기에 충분합니다. 아래에 매우 단순화된 코드(프로토타입)를 게시했습니다.
주목! 단순화를 위해 코드는 현재 기호의 순 부피만 계산합니다. 또한 현재 구현된 CHashMap에는 반복자가 포함되어 있지 않아 급하게 이러한 반복자를 만들었습니다. 수정된 CHashMap은 첨부 파일에 표시됩니다.
테스터 속도가 거래에 중요합니까? 그렇다면 HashMap도 거래에 영향을 미칩니다. TS의 개발 및 구현 속도를 높입니다.
테스터, 최적화 및 거래는 서로 다른 두 가지입니다.
같은 아이디어가 거래되고 최적화되지만 구현은 근본적으로 다를 수 있으며 이것도 부인할 수 없습니다.
데이터를 저장하고 검색하기 위해 이러한 효율적인 알고리즘을 사용해야 하는 작업의 특정 예입니다 . 옵티마이저의 경우 에도 거래가 없기 때문에 누군가 가져올 수 있습니까?
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
일반 클래스 라이브러리 - 버그, 설명, 질문, 사용법 및 제안
fxsaber , 2017.12.08 22:46
보다 현실적인 테스트 사례(2000개의 거래 및 1,000,000개의 단일 기록 액세스)의 경우 결과는 다음과 같습니다.
패스당 거의 100ms 절약! 예를 들어 10,000개의 전체 패스에 대해 최적화를 수행하면 해시 버전이 15분 더 빨리 종료 됩니다.
예 2: 순 계정에서 여러 Expert Advisors 거래
prev_deals = HistoryDealsTotal ();좋은 예! 편리합니다.
잊어버렸다
좋은 예! 편리합니다.
수정했습니다.
남의 것을 사용하는 것의 뉘앙스를 이해하고 의지하는 것보다 스스로 조립하기 쉬운 자전거가 있습니다.
제네릭은 그런 종류의 자전거가 아닙니다. 빠르고 정확하게 쓸 수 없습니다. 그들은 단지 추가할 것입니다.
훌륭한 이론적 예! 실제로, 누가 쓰레드를 언제-쓰레드가 수천 개의 트랜잭션으로 운영했습니까?
추신 나는 이것이 쓰레기이고 아무도 필요로하지 않는다는 것을 증명하려는 것이 아닙니다. 나는 실제 거래의 가치를 이해하려고 노력하고 있습니다. 저는 이론가가 아니라 순수한 실천가입니다.
실제로, 누가 쓰레드를 언제-쓰레드가 수천 개의 트랜잭션으로 운영했습니까?
Forts에서는 모든 것이 처음입니다.