나는 세 번째로 질문을 하려고 한다.) 여기MetaDriver 가 예를 보여주었다. 여기 내 예가 있습니다.
거래 횟수가 3000회를 넘으면 그래프가 축소됩니다. 개발자가 이 문제를 고려하고 있습니까?
이 문제로 인해 트랜잭션 수가 약 10,000개 이상일 수 있는 이력 데이터의 큰 섹션에 대해 시스템을 테스트할 때 터미널에서 즉시 트랜잭션 결과를 분석할 수 없습니다.
엑셀에도 비슷한게 있었던걸로 기억합니다. 그러나 복잡한 수식으로 인해 과부하가 발생했으며 행 수가 5000을 초과하면 프로그램이 중단되었습니다. 여기서 문제가 될 수 있는 것은 무엇입니까?
다음 빌드에서 수정 사항이 있을 것입니다. 다음과 같습니다.
이제 테스트 에이전트는 항상 에퀴티 밸런스 변경과 함께 정기적인 샌드를 보냅니다. 정보의 확대는 이제 클라이언트 터미널 측면에서 발생합니다. 변경 수가 16384를 초과하는 경우(유로 시간 시계에서 12년 동안 Moving Average.ex5에 대한 자본 잔액의 변경 수에 해당), 이미 도착한 데이터는 "포장"됩니다 - 2/5 10240개 레코드의 일부에서 레코드 중 일부가 삭제됩니다. 즉, 초기 데이터가 얇아집니다. 최신 데이터는 그대로 표시됩니다.
이제 테스트 에이전트는 항상 에퀴티 밸런스 변경과 함께 정기적인 샌드를 보냅니다. 정보의 확대는 이제 클라이언트 터미널 측면에서 발생합니다. 변경 수가 16384를 초과하는 경우(유로 시간 시계에서 12년 동안 Moving Average.ex5에 대한 자본 잔액의 변경 수에 해당), 이미 도착한 데이터는 "포장"됩니다 - 2/5 10240개 레코드의 일부에서 레코드 중 일부가 삭제됩니다. 즉, 초기 데이터가 얇아집니다. 최신 데이터는 그대로 표시됩니다.
챔피언십 전날(그리고 일반적으로 견고성을 위해 테스트도 농담이 아니며 MT4 대신 다음 구현을 위해) 데이터를 정리하는 것이 좋을 것입니다. 무엇보다도 터미널 시간(매우 중요, 예를 들어, 촛대 분석 및 모든 종류의 신경망, 증권 거래소에 대한 바인딩, 그리고 실제로 이벤트 빈도에 기반한 모든 TS에 대해 - 그리고 아마도 모두) 및 볼륨(볼륨) - 이는 다음을 구축하는 사람들을 위한 것입니다. 모든 종류의 누적 전문가 고문.
거래는 작업이고 실행 시간이 HistoryDealGetInteger (티켓,DEAL_TIME )이므로 거래에 마감 시간이 없습니다. ). 거래로 인해 포지션이 청산된 경우 지금이 포지션을 청산할 때입니다.PositionGetInteger 함수 의 속성에 POSITION_TIME 이라는 식별자가 있는 것은 이상 하지만 위치 열림 시간 이지만 위치 닫힘이 없습니다.
나는 세 번째로 질문을 하려고 한다.) 여기 MetaDriver 가 예를 보여주었다. 여기 내 예가 있습니다.
거래 횟수가 3000회를 넘으면 그래프가 축소됩니다. 개발자가 이 문제를 고려하고 있습니까?
이 문제로 인해 트랜잭션 수가 약 10,000개 이상일 수 있는 이력 데이터의 큰 섹션에 대해 시스템을 테스트할 때 터미널에서 즉시 트랜잭션 결과를 분석할 수 없습니다.
엑셀에도 비슷한게 있었던걸로 기억합니다. 그러나 복잡한 수식으로 인해 과부하가 발생했으며 행 수가 5000을 초과하면 프로그램이 중단되었습니다. 여기서 문제가 될 수 있는 것은 무엇입니까?
나는 그 문제를 지지한다! 같은 상황입니다. 사실 거래건수 때문인지 몰랐습니다. 이제 알았네요 감사합니다 :)
챔피언십 전날에 이 문제를 해결하는 것이 좋을 것입니다.
나는 세 번째로 질문을 하려고 한다.) 여기 MetaDriver 가 예를 보여주었다. 여기 내 예가 있습니다.
거래 횟수가 3000회를 넘으면 그래프가 축소됩니다. 개발자가 이 문제를 고려하고 있습니까?
이 문제로 인해 트랜잭션 수가 약 10,000개 이상일 수 있는 이력 데이터의 큰 섹션에 대해 시스템을 테스트할 때 터미널에서 즉시 트랜잭션 결과를 분석할 수 없습니다.
엑셀에도 비슷한게 있었던걸로 기억합니다. 그러나 복잡한 수식으로 인해 과부하가 발생했으며 행 수가 5000을 초과하면 프로그램이 중단되었습니다. 여기서 문제가 될 수 있는 것은 무엇입니까?
다음 빌드에서 수정 사항이 있을 것입니다. 다음과 같습니다.
이제 테스트 에이전트는 항상 에퀴티 밸런스 변경과 함께 정기적인 샌드를 보냅니다. 정보의 확대는 이제 클라이언트 터미널 측면에서 발생합니다. 변경 수가 16384를 초과하는 경우(유로 시간 시계에서 12년 동안 Moving Average.ex5에 대한 자본 잔액의 변경 수에 해당), 이미 도착한 데이터는 "포장"됩니다 - 2/5 10240개 레코드의 일부에서 레코드 중 일부가 삭제됩니다. 즉, 초기 데이터가 얇아집니다. 최신 데이터는 그대로 표시됩니다.
다음 빌드에서 수정 사항이 있을 것입니다. 다음과 같습니다.
이제 테스트 에이전트는 항상 에퀴티 밸런스 변경과 함께 정기적인 샌드를 보냅니다. 정보의 확대는 이제 클라이언트 터미널 측면에서 발생합니다. 변경 수가 16384를 초과하는 경우(유로 시간 시계에서 12년 동안 Moving Average.ex5에 대한 자본 잔액의 변경 수에 해당), 이미 도착한 데이터는 "포장"됩니다 - 2/5 10240개 레코드의 일부에서 레코드 중 일부가 삭제됩니다. 즉, 초기 데이터가 얇아집니다. 최신 데이터는 그대로 표시됩니다.
다음 빌드에서 수정 사항이 있을 것입니다.
SeriesInfoInteger ( symbo l ,0 , SERIES_SERVER_FIRSTDATE ) 함수에 대한 개발자의 의견이 있습니까 ? EA가 실행 중인 것과 다른 기호로 기록 시작 날짜를 요청하려고 하면 0을 반환합니다.
서비스 데스크에서 티켓 번호를 상기시키십시오(또는 요청하시기 바랍니다).
사소한 문제의 경우 서비스 데스크에 처리하는 것이 좋습니다.
서비스 데스크에서 티켓 번호를 상기시키십시오(또는 요청하시기 바랍니다).
사소한 문제의 경우 서비스 데스크에 처리하는 것이 좋습니다.
HistorySelect(), HistoryDealsTotal(), 테스터, 거래 모드: 임의 지연.
테스터에서 임의 지연 모드로 HistoryDealsTotal() 함수가 때때로
HistorySelect()를 사용하여 선택한 히스토리 섹션 의 거래 수를 잘못 결정합니다.
여기에 역사 시작 이후의 총 거래 수를 더합니다.
동시에 HistoryDealsTotal()의 값을 기반으로 HistoryDealGetTicket()을 사용하여 생성된 거래의 최종 목록
다음과 같이 보입니다. 거래 3; 거래 4; 거래 5; 거래 1; 거래 2; 거래 3; 거래 4; 거래 5;
여기서 거래 거래 3 - 거래 5는 사용자가 선택한 기간 동안의 거래입니다.
거래 마감 시간을 찾는 방법을 알려주십시오.
거래 속성에서 찾을 수 없습니다.