HistorySelect는 매우 비싼 기능입니다. 그러나 HistorySelectByPosition은 훨씬 더 비쌉니다.
예를 들어, 닫힌 위치의 첫 번째 거래를 찾아야 하는 경우 두 가지 방법으로 행동할 수 있습니다.
HistorySelectByPosition을 만든 다음 결과 작은 목록에서 원하는 거래를 찾으십시오. 그러나 이 목록은 다음과 같이 구성됩니다. 먼저 ALL 이력이 구성됩니다("무한" HistorySelect 호출과 동일). 그런 다음 이 목록을 통해 FULL for 루프가 있고 해당 POSITION_IDENTIFIER가 있는 트랜잭션만 선택됩니다.
HistorySelect를 수행("무한"할 수 있지만 알려진 경우 간격을 사용하는 것이 좋습니다)한 다음 for 루프에서 해당 DEAL_ENTRY에 도달하면 중단을 수행합니다.
두 번째 항목은 상당히 저렴할 수 있습니다. 그러나 확실히 더 비싸지는 않습니다.
테스터에서 HistorySelect* 함수를 호출하는 것은 거의 계산 자원 의 낭비입니다. 따라서 항상 그 수를 최소한으로 줄이려고 노력해야 합니다. 특히, HistorySelectByPosition.
template < typename T>
T GetValue()
{
T Res; // possible use of uninitialized variable 'Res'return (Res);
}
voidOnStart ()
{
MqlTick Tick = GetValue< MqlTick >();
int i = GetValue< int >();
}
생활 해킹
template < typename T>
const T GetDefaultValue( void )
{
struct STRUCT_TYPE
{
const T Value;
};
const STRUCT_TYPE Res = { 0 };
return (Res.Value);
}
voidOnStart ()
{
int i = GetDefaultValue< int >();
MqlTick Tick = GetDefaultValue< MqlTick >();
string Str = GetDefaultValue< string >();
}
HistorySelect는 매우 비싼 기능입니다. 그러나 HistorySelectByPosition은 훨씬 더 비쌉니다.
예를 들어, 닫힌 위치의 첫 번째 거래를 찾아야 하는 경우 두 가지 방법으로 행동할 수 있습니다.
두 번째 항목은 상당히 저렴할 수 있습니다. 그러나 확실히 더 비싸지는 않습니다.
테스터에서 HistorySelect* 함수를 호출하는 것은 거의 계산 자원 의 낭비입니다. 따라서 항상 그 수를 최소한으로 줄이려고 노력해야 합니다. 특히, HistorySelectByPosition.
테스터의 헤지 계정의 경우 이는 테스터의 결과가 계정 유형에 크게 의존한다는 것을 의미합니다.
이웃 브랜치 중 하나에서 밝혀졌듯이 테스터의 결과는 테스트가 로컬 에이전트에서 수행되는지 아니면 분산 네트워크의 에이전트 중 하나에서 수행되는지에 따라 달라집니다.
https://www.mql5.com/ru/forum/1111/page1880#comment_4904481
이웃 브랜치 중 하나에서 밝혀졌듯이 테스터의 결과는 테스트가 로컬 에이전트에서 수행되는지 아니면 분산 네트워크의 에이전트 중 하나에서 수행되는지에 따라 달라집니다.
https://www.mql5.com/ru/forum/1111/page1880#comment_4904481
이 스레드의 컨텍스트에 없는 BAG를 설명했습니다. 지정가 주문 실행의 차이는 공식 입장입니다.
동의합니다. 테스터가 점점 더 예측할 수 없는 도구가 되고 있다는 점을 말씀드리고 싶습니다.
동의합니다. 테스터가 점점 더 예측할 수 없는 도구가 되고 있다는 점을 말씀드리고 싶습니다.
이것은 테스터의 결과가 계정 유형에 크게 의존한다는 것을 의미합니다.
결과
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
fxsaber , 2017.04.10 16:53
개발자 여러분, 이러한 상황에서 경고를 제거하는 방법은 무엇입니까?기본 기능(필요하지 않음)