누락된 막대 없이 차트를 보고 싶은 사람 - 여기 =) - 페이지 9

새 코멘트
 
왜 개발자들이 오프라인 차트에서 전문가의 작업을 금지했는지 알았습니다.
오프라인 차트의 경우 Bid와 Ask가 0을 반환하기 때문인 것 같은데, 마켓에 오픈을 원하는 Expert Advisors에게는 불가능합니다. 그러나 연기에만 전념하는 전문가를 위해 다음과 같은 문제 해결 방법을 생각해 냈습니다. 자동 수정을 사용하여 Bid 및 Ask를 _Bid() 및 _Ask()로 변경합니다. _MarketInfo()는 거래되는 상품의 스프레드를 반환합니다.

 int _MarketInfo ( string symb_for_work )
{
   if ( symb_for_work == " USDCHFm " ) return ( 4 ) ;
   if ( symb_for_work == " CHFJPYm " ) return ( 5 ) ;
   if ( symb_for_work == " GBPUSDm " ) return ( 3 ) ;
   if ( symb_for_work == " USDCADm " ) return ( 5 ) ;
   if ( symb_for_work == " USDJPYm " ) return ( 3 ) ;
   if ( symb_for_work == " EURGBPm " ) return ( 4 ) ;
   if ( symb_for_work == " AUDUSDm " ) return ( 4 ) ;
   if ( symb_for_work == " EURCHFm " ) return ( 4 ) ;
   if ( symb_for_work == " EURJPYm " ) return ( 5 ) ;
   if ( symb_for_work == " EURUSDm " ) return ( 2 ) ;
   if ( symb_for_work == " NZDUSDm " ) return ( 6 ) ;
   if ( symb_for_work == " AUDJPYm " ) return ( 6 ) ;   
 
return ( 0 ) ;
}
 
double _Bid ()
{
   return ( Close [ 0 ]) ;
}
 
double _Ask ()
{
   return ( Close [ 0 ] + _MarketInfo ( symbol_for_trade ) * Point ) ;
}
일반적으로 아이디어가 명확하다고 생각합니다. 수정된 Expert Advisor의 첫 번째 결과로 판단하면 주문이 정상적으로 열립니다. 이제 정말 이미 주말이고 다음 주에 거래가 시작되면 더 자세히 테스트하겠습니다. 처음에는 받고 싶은 것을 완성할 수 있을 거라고 생각합니다.
 
아이고, 쓰레기...
개발자가 "오프라인 차트의 경우 입찰 및 매도가 0을 반환함"을 확인했다면,
그들이 그것을 고치는 것을 막는 것은 무엇입니까?
 

예를 들어, 오프라인 차트는 아주 드물게 업데이트될 수 있습니다. 그리고 예를 들어 1-2분의 업데이트 간격 동안 실제 Ask 및 Bid는 오프라인 차트에 표시되는 것보다 충분히 멀리 갈 수 있습니다. 그리고 RefreshRates ()는 여기서 전혀 도움이 되지 않습니다. 이미 언급한 이유 외에 다른 이유가 있었을 것입니다. 그러나 개발자만이 이에 답할 수 있습니다.

 
solandr :

예를 들어, 오프라인 차트는 아주 드물게 업데이트될 수 있습니다. 그리고 예를 들어 1-2분의 업데이트 간격 동안 실제 Ask 및 Bid는 오프라인 차트에 표시되는 것보다 충분히 멀리 갈 수 있습니다. 그리고 RefreshRates ()는 여기서 전혀 도움이 되지 않습니다. 이미 언급한 이유 외에 다른 이유가 있었을 것입니다. 그러나 개발자만이 이에 답할 수 있습니다.

맞습니다. 차트가 업데이트되지 않으면 입찰가가 무용지물이 됩니다.
그러나 Close[0]도 마찬가지입니다!

거래 고문에서 고의로 잘못된 가격을 사용할 수 없습니다.
MarketInfo( MODE_BID ) 및 MarketInfo( MODE_ASK )를 사용하여 최신 가격을 얻으십시오)
 

예, 원칙적으로 인질과 놀 때 몇 분 동안 오래된 Close[0]에 상당히 만족합니다. o)
나는별로 급하지 않아. 나는 고의적으로 "느리게" ;o) 다음 원칙에 따라 후발자 수정에 대한 고문의 작업:

1. 현재 가격 이 폰에서 50핍보다 가깝지 않은 경우 전문가에 의한 폰 수정은 주문을 10핍 이상 이동해야 하는 경우에만 허용됩니다.
2. 현재 가격이 세터에서 25...50핍 범위에 있는 경우 Expert Advisor는 세터를 5핍 이상 이동해야 하는 경우에만 세터를 이동할 수 있습니다.
3. 현재 가격이 주문에 25핍보다 가까우면 어드바이저가 폰을 2핍 이상 움직입니다.

그러한 계획을 통해 구금자의 이동 횟수를 줄일 수 있었습니다. 적어도 5분의 1 이상은 아니더라도 말이죠! :o) 시간당 평균 0회(야간)에서 20회(뉴스 중) 이동으로 밝혀져 총 약 60개의 연체자(12개 통화에 대해)가 발생합니다! 즉, 하루에 200개 이하의 움직임이 있을 수 있으며 심지어 매일은 아닐 수도 있습니다. 일반적으로 수동으로 거래할 때 특정 전략을 정확히 따르고 같은 수의 통화 쌍을 플레이하면 사람들이 주문을 훨씬 더 많이 이동할 수 있다고 생각합니다! ;영형)

 

komposter , 일요일부터 월요일까지 일광 초를 꿰매는 전문가를 개발해 주셔서 다시 한 번 큰 감사를 드립니다!!!
나는 이제 한 달 동안 실생활에서 당신의 대본으로 작업하고 있습니다. 각각 600개의 일일 막대가 있는 19개의 통화 쌍(모두 InterbankFX에서 사용 가능)을 처리하기 위해 스크립트를 실행하고 차트 업데이트 시간을 1분으로 설정합니다. 모든 것이 VIA C3 800MHz 프로세서에서 완벽하게 작동합니다!

나는 하나의 작은 기능을 발견했습니다. 이것은 개인적으로 불만이없는 전문가가 아니라 터미널의 기능이라고 가정합니다! Expert Advisor가 실행 중이고 Metaeditor에서 차트에 일시 중단되지 않은 Expert Advisor를 컴파일하면 터미널 로그에 오류가 발생합니다. 동시에 이 사실은 800MHz 프로세서와 P4 3GHz 및 Celeron 2GHz 모두에서 안정적으로 나타납니다. 198 빌드
******************************
2006.12.09 03:26:29 WithoutSunday_4: FileFlush 의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileFlush의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileFlush의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileFlush의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileFlush의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileFlush의 잘못된 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteDouble의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileWriteInteger의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4: FileSeek의 유효하지 않은 핸들 -1
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,매일: 경고: FileOpenHistory( "WS_AUDNZDm1440.hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,매일: 경고: FileOpenHistory( "WS_NZDJPYm1440. hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,매일: 경고: FileOpenHistory( "WS_AUDCADm1440. hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory( "WS_EURCADm1440.hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,매일: 경고: FileOpenHistory( "WS_EURAUDm1440. hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
2006.12.09 03:26:29 WithoutSunday_4 EURUSDm,매일: 경고: FileOpenHistory( "WS_GBPCHFm1440. hst", FILE_BIN | FILE_WRITE ) - 오류 #4102
2006.12.09 03:26:29 WithoutSunday_4: FileOpen - 열린 파일이 너무 많음
*******************************

일반적으로 등장한 후 터미널을 재부팅하면 모든 것이 24 시간 내내 일반 모드에서 계속 작동합니다!
나는 이것을 단순히 정보로 쓰는 것이지, 문제를 해결하려고 하는 것이 아닙니다. 나는 여기에서 개발자의 도움 없이는 불가능하다고 생각합니다.

부탁이 있어 글을 씁니다. 이 스크립트에서 생성된 인용문을 기반으로 이 스레드에서 위에서 언급한 선형 및 포물선 회귀 채널 계산을 위한 Expert Advisor가 저에게 효과적입니다. 회귀 계산은 막대의 평균 매개변수를 기반으로 합니다. 즉, 값 (O+H+L+C)/4를 참조로 사용합니다. 그러나 장기간 관찰한 결과 이 샘플링 모델(O + H + L + C) / 4가 잘 선택되지 않았다는 가정이 있습니다. 95% 신뢰구간의 경계선에서 열린 주문에 대해 99.9% 경계선에 놓았습니다. 그래서 가격이 99.9% 신뢰구간을 몇 핍만 넘어간 경우가 있습니다. 동시에 이러한 경우의 수는 통계 데이터에 따라 허용 값보다 높습니다! 따라서 고가 및 종가 모델을 계산의 기준으로 삼으면 이 경계가 통계적으로 더 정확하게 제공된다는 제 가정을 확인하고 싶습니다. Expert Advisor는 mq4 파일에서 184kB로 매우 부피가 큽니다. 많은 곳에서 인용구에 호소합니다. 새 모델에 대해 Expert Advisor를 수정하기 시작하면 상당히 힘들고 제 생각에는 이미 테스트된 다소 복잡한 계산 알고리즘에 오류가 발생할 가능성이 매우 높습니다. 잘 작동하고 안정적으로 작동합니다.

따라서 수신된 일간 캔들에서 H12 기간 호가를 생성하는 방식으로 스크립트의 마지막 버전을 수정해 주시길 부탁드립니다.
00:00에 열리는 H12봉은 원래 일간봉의 O=H=L=C=낮은 값이어야 합니다.
12시에 여는 H12바는 원래 일봉의 O=H=L=C=높은 값이어야 합니다.
또한 전문가는 이러한 값을 교환할 수 있어야 합니다. 즉, 00:00의 막대 H12 = 원래 일봉의 고점, 12:00의 막대 H12 = 원래 일봉의 저점입니다.
실시간 작업 중 차트를 업데이트할 때 현재 날짜의 마지막 H12 막대는 처리 없이 EA에 의해 전송되어야 합니다. 즉, 각 H12 막대에 대한 현재 값이 O,H,L,C입니다.
막대의 설명된 처리는 마감일의 H12 막대에 더 이상 변경 사항이 발생하지 않을 때 일간 양초가 마감된 후에만 이루어져야 합니다.
설명된 방법에 따라 기존 스크립트를 수정하는 데 도움이 될 수 있다면 채널링의 통계적 분석 측면에서 High-Low 모델을 매우 빠르게 검증할 수 있습니다. 여기에서 비교 결과를 발표할 것을 약속합니다. 통계 데이터 처리에 관심이 있는 많은 분들이 관심을 갖고 알게 되리라 생각합니다. 미리 감사합니다!!!

 
solandr :

InterbankFX에서 업데이트할 때 발생하는 몇 가지 문제(업데이트 초대가 표시되지만 빌드가 다운로드되지 않지만 더 이상 중요하지 않음)

새로운 실제 서버에서 실제로 업데이트되지 않습니다. Liveupdate는 문제 없이 데모 서버에 연결합니다.
 

내 부분에서는 먼저 High에 대해서만 채널 계산을 확인하고 Low에 대해서만 별도로 확인하려고 합니다. 나는 결과를 볼 것이다. 다른 샘플에서 얻은 채널의 길이가 같으면 H12 기간 동안 새 스크립트 없이도 가능합니다. 즉, 채널 의 상한 은 계산 데이터를 High로, 하한은 데이터를 Low로 사용합니다. 그리고 갑자기 모든 것이 내 Expert Advisor에서 훨씬 쉽게 해결될 수 있다면 아무 것도 요구하지 않는 것으로 당신을 귀찮게 합니다. 내 Expert Advisor에서 구현하는 것은 어렵지 않다고 생각합니다.

 
komposter 여기에서 문제가 발생했습니다. 무엇을 수정할 것인지 묻지 않을 것입니다. 모든 세부 정보는 여기 http://forum.kimiv.ru/viewtopic.php?t=177
 
solandr :

나는 하나의 작은 기능을 발견했습니다. 이것은 개인적으로 불만이없는 전문가가 아니라 터미널의 기능이라고 가정합니다! Expert Advisor가 실행 중이고 Metaeditor에서 차트에 일시 중단되지 않은 Expert Advisor를 컴파일하면 터미널 로그에 오류가 발생합니다.

휴가에서 돌아와서 답변이 너무 길어서 죄송합니다...

내가 보기에 문제는 Expert Advisor가 열린 파일을 닫지 않는다는 것입니다. 문제는 그가 그것을하지 않는 이유입니다 =)
유일한 가정은 함수 실행을 컴파일할 때 Expert Advisors 작업의 시작이 강제로 종료된다는 것입니다.

그리고 다음 "시작"에서 파일이 다시 열리지만 이미 "공간이 충분하지 않습니다"(최대 32개의 열린 파일 ).

EA 자체는 이 상황을 잘못 처리합니다. 파일이 열리지 않더라도 거기에 데이터 쓰기를 시도합니다.
실수 수정 - 한 줄 추가 =)
if ( HistoryHandle[curChart] < 0 ) 계속;


첨부된 전문가입니다.



H12 차트의 경우. "나는 시간은 있지만 돈이 없다" - 그것은 나에 관한 것이 아니다 =)
나는 또한이 두 값이 반비례 관계에 있지만 자유 시간이 많을수록 돈이 적고 그 반대도 마찬가지입니다.

자, 저는 자선 활동을 할 수 없습니다. 일이 많습니다.
그리고 아직 읽지 않은 포럼 페이지(*30개 주제)가 5개 있습니다.
파일:
withoutsunday.mq4  12 kb
123456789101112
새 코멘트