일반 클래스 라이브러리 - 버그, 설명, 질문, 사용 기능 및 제안 사항 - 페이지 13

새 코멘트
 
레나트 파트훌린 :

HistorySelect(테스터에서 액세스 범위 설정)와 실제로 특정 티켓을 검색하고 캐시하는 HistoryDealSelect(티켓)를 비교할 수 없습니다.

이러한 이해로 인해 Clear 버전이 바로 만들어졌습니다. Clear와 Full을 동시에 비교할 수 있습니다.

 
fxsaber :
따라서 히스토리(특히 테스터에서)는 보완만 되며 이전 레코드는 변경되지 않습니다. 지우기 옵션에 관한 것입니다.


실생활에서 주문이 부분적으로 실행되어 여러 트랜잭션이 발생하더라도 완전히 채워지거나 취소될 때까지 내역에 입력되지 않는 것 같습니다. 저것들. 동결된 역사 규칙이 유지됩니다.

검사 없이 소프트웨어를 작성했다면 모든 것이 오래전에 무너졌을 것입니다.

금융 소프트웨어는 "모서리 절단" 모드에서 작성하는 것을 허용하지 않습니다. 한 곳에서 자르고 다른 곳으로 자르면 개발자는 힘든 검사를 건너뛸 권리가 있다고 믿으며 실패는 불가피합니다.

테스터에서는 여전히 확인을 약화시킬 수 있지만 실제 생활에서는 Expert Advisor의 작업과 병행하여 전체 시장 환경에서 끊임없는 변화에 대해 작업하는 많은 비동기식 프로세스가 있습니다. MQL5 호출 사이에 무언가가 저장될 것이라고 생각하면 끔찍합니다.

 
레나트 파트훌린 :

검사 없이 소프트웨어를 작성했다면 모든 것이 오래전에 무너졌을 것입니다.

금융 소프트웨어는 "모서리 절단" 모드에서 작성하는 것을 허용하지 않습니다. 한 곳에서 자르고 다른 곳으로 자르면 개발자는 힘든 검사를 건너뛸 권리가 있다고 믿으며 실패는 불가피합니다.

테스터에서는 여전히 확인을 약화시킬 수 있지만 실제 생활에서는 Expert Advisor의 작업과 병행하여 전체 시장 환경에서 끊임없는 변화에 대해 작업하는 많은 비동기식 프로세스가 있습니다. MQL5 호출 사이에 무언가가 저장될 것이라고 생각하면 끔찍합니다.

설명 감사합니다! 테스터님, 조금 수정해주셨으면 합니다.

 
fxsaber :

이러한 이해로 인해 Clear 버전이 바로 만들어졌습니다. Clear와 Full을 동시에 비교할 수 있습니다.

당신은 당신이 테스트 한 것을 오해하고 있습니다. 이것은 어떤 식으로든 지우기 옵션이 아니며 처음에 HistorySelect 에 대해 선언된 참조와 관련이 없습니다.

전체 옵션은 본질적으로 이중 호출(티켓 검색)을 의미하며, 첫 번째는 캐시에서 거래를 선택하고 두 번째는 캐시된 결과에 액세스합니다. 거래가 존재하는 것으로 알려진 특정 문제에서 첫 번째 선택 호출은 중복됩니다. Get 메서드는 영향을 받는 항목을 캐시에 암시적으로 푸시합니다.



정보: 개발자가 실패의 근본 원인을 얻을 수 있도록 내부적으로 자세한 마지막 오류 코드(GetLastError() 호출 아래)를 노출해야 합니다. 일반적으로 플랫폼 깊숙한 곳에서 호출당 몇 가지 이러한 검사가 있습니다.
 
레나트 파트훌린 :

당신은 당신이 테스트 한 것을 오해하고 있습니다. 이것은 어떤 식으로든 지우기 옵션이 아니며 처음에 HistorySelect에 대해 선언된 참조와 관련이 없습니다.

눈치채지 못한 모양입니다.

거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼

일반 클래스 라이브러리 - 버그, 설명, 질문, 사용법 및 제안

fxsaber , 2017.12.08 22:46 

  BENCH( HistorySelect ( 0 , INT_MAX ) );
  BENCH( Print (SumProfit(Deals, GetDealProfitClear))); // Реализация с предварительно загруженной историей
아니면 다른 것에 대해 이야기하고 있는지도 모릅니다.
 
fxsaber :

눈치채지 못한 모양입니다.

아니면 다른 것에 대해 이야기하고 있는지도 모릅니다.

주목.

사전 로드된 스토리는 무엇입니까? 테스터의 HistorySelect는 가짜 이며 실제로 요청에 지정된 전체 기록을 캐시로 전송하지 않고 기존 트랜잭션 데이터베이스의 위치만 표시한다고 지적했습니다. 따라서 비용은 0입니다.

GetDealProfitClear에서는 HistoryDealGetDouble (Deal, DEAL_PROFIT )을 통해 잘못 이해한 GetDealProfitFull 메서드와 동일한 방식으로 요청합니다. 정확히 동일한 물리적 메서드가 두 개 있습니다.

 return ( HistoryDealSelect (Deal) ? HistoryDealGetDouble (Deal, DEAL_PROFIT ) : 0 )

즉, 테스터의 기록에 대한 액세스는 매우 최적화되어 있으며 Expert Advisor를 제외하고는 아무도 거래 기록을 변경할 수 없다는 사실에 중점을 둡니다(아직 확인 사항이 있음).

실제 터미널에서는 모든 것이 다르며 HistorySelect가 비쌉니다.

 
레나트 팻쿨린 :

무슨 말인지 이해했습니다. 세부정보 감사합니다! 당신이 무엇을 끝내고 궁금해

거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼

일반 클래스 라이브러리 - 버그, 설명, 질문, 사용법 및 제안

레나트 팻쿨린 , 2017.12.08 23:19

나는 우리의 코드를 살펴보았다. 거래 작업의 데이터베이스에 대한 호출을 최적화하는 것이 가능하다. 다음 주 출시를 위해 구현하려고 합니다.

그리고 일반 테마는 매우 유용합니다! 관심을 가지고 따르겠습니다.
 

CHashMap 의 구현에 대해 알게 되었습니다.
 솔직히, 나는 그것을 좋아했다.

 //+------------------------------------------------------------------+
//| Class CHashMap<TKey, TValue>.                                    |
//| Usage: Represents a collection of keys and values.               |
//+------------------------------------------------------------------+
template<typename TKey,typename TValue>
class CHashMap: public IMap<TKey,TValue>
  {
protected :
   int                m_buckets[];                        
   Entry<TKey,TValue>m_entries[];
   int                m_count;
   int                m_free_list;
   int                m_free_count;
   IEqualityComparer<TKey>*m_comparer;
   bool               m_delete_comparer;

public :
                     CHashMap( void );
                     CHashMap( const int capacity);
                     CHashMap(IEqualityComparer<TKey>*comparer);
                     CHashMap( const int capacity,IEqualityComparer<TKey>*comparer);
                     CHashMap(IMap<TKey,TValue>*map);
                     CHashMap(IMap<TKey,TValue>*map,IEqualityComparer<TKey>*comparer);
                    ~CHashMap( void );
   //--- methods of filling data 
   bool               Add(CKeyValuePair<TKey,TValue>*pair);
   bool               Add(TKey key,TValue value );
   //--- methods of access to protected data
   int                Count( void )                                       { return (m_count-m_free_count); }
   IEqualityComparer<TKey>*Comparer( void )                         const { return (m_comparer);           }
   bool               Contains(CKeyValuePair<TKey,TValue>*item);
   bool               Contains(TKey key,TValue value );
   bool               ContainsKey(TKey key);
   bool               ContainsValue(TValue value );
   //--- methods of copy data from collection   
   int                CopyTo(CKeyValuePair<TKey,TValue>*&dst_array[], const int dst_start= 0 );
   int                CopyTo(TKey &dst_keys[],TValue &dst_values[], const int dst_start= 0 );
   //--- methods of cleaning and deleting
   void               Clear( void );
   bool               Remove(CKeyValuePair<TKey,TValue>*item);
   bool               Remove(TKey key);
   //--- method of access to the data
   bool               TryGetValue(TKey key,TValue & value );
   bool               TrySetValue(TKey key,TValue value );

private :
   void               Initialize( const int capacity);
   void               Resize( int new_size, bool new_hash_codes);
   int                FindEntry(TKey key);
   bool               Insert(TKey key,TValue value , const bool add);
  };


가능한 개선을 위한 몇 가지 제안 사항이 있습니다.

1) 내 겸손한 의견으로는 구현에 완전히 올바르지 않은 용량 선택이 포함되어 있습니다. 초기 크기 3과 해시 테이블이 다시 빌드될 때 후속 크기 모두입니다.
네 맞습니다. 균일 분포를 위해서는 소수를 선택해야 합니다.
그러나 CPrimeGenerator의 구현은 기대에 미치지 못하고 누락된 소수를 포함합니다.
이러한 "생성기"의 목적은 명확합니다. 자동으로 소수를 생성하여 1.2 정도의 성장 인자를 제공하는 것입니다.
하지만, 너무 작은 요소가 아닌가? 벡터에 대한 C++에서 계수는 일반적으로 라이브러리에 따라 1.5-2.0입니다(연산의 평균 복잡성에 크게 영향을 미치기 때문에).
출력은 상수 계수일 수 있으며 소수 목록에서 이진 검색을 통해 숫자를 소수로 반올림할 수 있습니다.
그리고 3의 초기 용량 크기는 너무 작습니다. 우리는 지난 세기에 살고 있지 않습니다.

2) 현재 해시 테이블의 재구축(Resize)은 100% 채우기(모든 m_entries[] 채우기)로만 수행됩니다.
이와 관련하여 매우 균일하지 않은 분포를 갖는 키에 대해 상당한 수의 충돌이 가능합니다.
옵션으로 해시 테이블 재구축을 수행하는 데 필요한 제한만큼 100% 감소하는 채우기 비율을 도입하는 것을 고려하십시오.

 
fxsaber :

그리고 귀하의 경우 클래식 버전은 얼마를 반환합니까?

 ulong GetDealOrder( const ulong Deal )
{
   return ( HistoryDealSelect (Deal) ? HistoryDealGetInteger (Deal, DEAL_ORDER ) : 0 );
}
 2017.12 . 08 17 : 56 : 05.184 OrdersID (SBRF Splice,M1)       Время выполнения запроса: 9 микросекунд

이것은 printf 실행 시간입니다.

당신은 어떻게 든 내 예를 오해했습니다. 저는 MetaTrader의 표준 기능과 아무 것도 비교할 생각이 없습니다. 사용자 수준에서 어떤 것과의 연관 및 샘플링을 위한 효과적인 알고리즘을 구성하는 방법에 관한 것입니다. 거래 번호와 주문 번호를 연결하는 예는 실용 가치가 낮기 때문에 하나의 예로만 고려해야 합니다. 시스템 HistoryDealGetInteger (Deal, DEAL_ORDER )가 있습니다.

 
fxsaber :

자, 선택한 두 지표를 비교해 보겠습니다. HashMap 액세스가 개발자보다 4배 빠른 것으로 나타났습니다. 그러나 개발자에게는 이미 역사가 포함되어 있습니다 ...

같은 이유로 비교가 잘못되었습니다. 사용자 정의 CHashMap을 비교하고 시스템 기능을 사용하여 거래 환경을 얻으려면 어떻게 해야 합니까?

1...67891011121314151617181920...38
새 코멘트