가장 낮은 함수와 가장 높은 함수가 반환하는 것 - 페이지 6

 
저도 이 상황에서는 스와핑이 아니라 히스토리가 스왑되기를 기다리지 않고 새로운 바가 만들어지기 시작한다는 말이 더 맞을 것 같다는 생각도 했습니다. 그리고 그것은 일종의 권리입니다. 그러나 다른 한편으로 거래 전문가 고문을 상상해 봅시다. 통신이 실패하면 통신이 복원됩니다. 기록이 완전히 바뀌기 전에 Expert Advisor는 잘못된 지표 값을 기반으로 포지션을 열 시간이 있을 수 있습니다. 즉, 질문은 이 주제의 범위를 넘어서 일반적으로 자동차 거래의 보안과 관련됩니다. 문제는 물론 쉽지 않습니다. 출력이 "역사의 마지막 연속 섹션 길이"가 미리 정의된 변수 가 될 수 있습니까? 지표(전문가)는 그것을 읽고 어떻게든 상황을 처리할 수 있습니다.
 
여기에 Bar 값(Time[0] 뿐만 아니라)을 저장하는 것이 도움이 될 수 있습니다. 즉:

 시작()
{.....
if (PrevBars!=Bars-1) 
{
초기화();
PrevBars=막대-1;
}
 
진지한 거래를 전문가 고문으로 만드는 사람들은 아마도 이 문제를 알고 있을 것입니다. 그리고 이러한 상황에 대한 일부 처리는 Expert Advisor에 포함됩니다.
 
이것은 Bar의 값(Time[0] 뿐만 아니라)을 저장하는 것이 도움이 될 수 있는 곳입니다....

다음은 해당 로그 조각 의 일부입니다. 새 막대 가 시작될 때 막대가 1만큼 증가하고 교체할 막대 수가 증가하지 않음을 보여줍니다. 즉, 도움이 되지 않습니다.
 2006.10.31 23:58:25 CZZ2 EURUSD,M1: shift=0, 막대=38230, 시간[shift]=2006.10.31 22:51, 높음[shift]=1.2763, 낮음[shift]=1.2763
2006.10.31 23:58:25 CZZ2 EURUSD,M1: shift=1, 막대=38230, 시간[shift]=2006.10.31 22:45, 높음[shift]=1.2762, 낮음[shift]=1.2762
2006.10.31 23:58:23 CZZ2 EURUSD,M1: shift=0, 막대=38229, 시간[shift]=2006.10.31 22:45, 높음[shift]=1.2762, 낮음[shift]=1.2762



진지한 거래를 전문가 고문으로 만드는 사람들은 아마도 이 문제를 알고 있을 것입니다. 그리고 이러한 상황에 대한 일부 처리는 Expert Advisor에 포함됩니다.

글쎄, 어떻게 든 상황을 처리하려고 시도 할 수 있지만 비뚤어진 종소리 없이는 할 수없는 것처럼 보입니다. 특히 구멍이 없는 차트에서 MQ의 타이트한 위치를 고려할 때.
반면에 단말은 히스토리 다운로드가 필요한지 여부를 압니다. MQL에서 이 지식에 액세스했다면 문제가 훨씬 더 자연스럽게 해결되었을 것입니다.


 
그런 다음 Time[0] 시간과 Time[1] 시간을 비교합니다. 나 자신도 그런 상황에 딱 한 번 싸워본 적이 없어서 당장 실용적인 코드를 제시할 수는 없다.
 
그런 다음 Time[0] 시간과 Time[1] 시간을 비교합니다. 나 자신도 그런 상황에 딱 한 번 싸워본 적이 없어서 당장 실용적인 코드를 제시할 수는 없다.

구멍의 존재는 MT의 표준 상황이기 때문에 "구멍 없는 플롯" 유형 코드를 미리 고정하지 않으면 아무 작업도 수행하지 않습니다. 시간이 많이 걸리더라도 이를 통해 거의 모든 실패 사례를 감지할 수 있습니다.
 
사실 이것은 어느 정도 "악마화"입니다. :)
데이터 스와핑은 터미널의 오류뿐만 아니라 공급자, 데이터 센터, 브로커, 컴퓨터 정지 등의 오류를 통해 발생할 수 있으므로 최대한 보호하여 코드를 작성해야 합니다.
 
그건 그렇고, 만일을 위해. 28. 극단적인 가격 검색 - http://www.alpari-idc.ru/ru/experts/articles/29.html
 
최대한의 보호 기능을 갖춘 코드는 실용에 적합하지 않을 것 같습니다. :). 일반적으로 거래는 위험한 사업이므로 합리적인 보호를 받을 수 있습니다. 그러나 여기서 우리는 상당히 일반적인 상황에 대해 이야기하고 있습니다. 그건 그렇고, 이전 게시물에서 큰 시간 프레임의 더 큰 보안에 대한 나의 결론은 잘못되었습니다. 히스토리 스왑 전에 이전 막대에는 잘못된 고가, 저가 및 종가 값이 있을 수 있고 현재 막대에는 잘못된 고가, 저가 및 시가 값이 있을 수 있습니다.
 
마지막 두 막대에 대한 데이터의 정확성을 결정하는 간단한 방법이 없기 때문에 큰 기간이 작은 기간보다 훨씬 더 위험한 것으로 나타났습니다. 표시기가 의사록에 매달려 있고 GoodHistoryDepht 전역 변수 를 채우는 것을 상상할 수 있습니다. 다른 지표는 이 값을 필요한 계산 깊이와 비교하여 결정을 내립니다. 그러나 홀에 대한 MQ의 위치로 인해 상당한 시간(시간 범위가 클수록 더 커지고 일일 바가 완전히 거부될 때까지)은 거래에 적합하지 않습니다. 특히 통신 실패가 실제 계정으로 사는 것을 선호한다는 점을 고려하면.