모두 좋은 저녁입니다. 제가 뭔가 잘못 이해하고 있는 것일 수도 있지만, Bars()의 시작 부분에서 이미 제안된 표준 함수가 왜 적합하지 않은지 완전히 명확하지 않습니다. 나는 항상 그것을 사용하고 문제가 없습니다. 나중에 만날 수 있는 유일한 것은 TimeCurrent() 를 사용할 때 "범위를 벗어난 배열" 또는 음수 값이지만 그에 따라 확인해야 합니다. 예:
//найти бар на котором продали
Bar_sell_H4= Bars ( Symbol (), PERIOD_H4 ,P_opentime, 32000000000 )- 1 ;
if (Bar_sell_H4<= 0 )
{
Bar_time_sell_H4=Time_H4[ 0 ];
}
else
{
Bar_time_sell_H4=Time_H4[Bar_sell_H4];
}
모두 좋은 저녁입니다. 제가 뭔가 잘못 이해하고 있는 것일 수도 있지만, Bars()의 시작 부분에서 이미 제안된 표준 함수가 왜 적합하지 않은지 완전히 명확하지 않습니다. 나는 항상 그것을 사용하고 문제가 없습니다. 나중에 만날 수 있는 유일한 것은TimeCurrent() 를 사용할 때 "범위를 벗어난 배열" 또는 음수 값이지만 그에 따라 확인해야 합니다. 예:
숫자 32000000000으로 보아 이것도 내 창작물이다. UINT_MAX는 더 짧고 더 단단해 보입니다. ))
사실이 옵션이 더 정확하다는 것이 밝혀졌습니다.
Bars (Symb,TimeFrame,time+ 1 , UINT_MAX );
하지만
Bars (Symb,TimeFrame,time, UINT_MAX )- 1 ;
외적인 차이는 거의 없습니다. 하지만 반면에 상위 버전은 MQL4의 표준 iBarShift 기능을 매우 정확하게 반복합니다.
모든 것이 MQL4에서처럼 작동해야 한다고 말씀하셨습니다.
그러나 이 스크립트는 MQL5에서도 실행할 수 있습니다.
정확=참 및 미래 시제를 사용하면 -1을 반환해야 합니다.
그리고 내 스크립트는 당신에게서 이상한 오류를 발견했습니다.
이 오류는 다음 검사로 확인됩니다.
그래서 나는 당신의 알고리즘에 비정상적인 상황이 존재한다는 것에 대해 여전히 옳았습니다.드디어 버그를 찾으셨다니 다행입니다.
확인하겠습니다. 감사합니다.
모두 좋은 저녁입니다. 제가 뭔가 잘못 이해하고 있는 것일 수도 있지만, Bars()의 시작 부분에서 이미 제안된 표준 함수가 왜 적합하지 않은지 완전히 명확하지 않습니다. 나는 항상 그것을 사용하고 문제가 없습니다. 나중에 만날 수 있는 유일한 것은 TimeCurrent() 를 사용할 때 "범위를 벗어난 배열" 또는 음수 값이지만 그에 따라 확인해야 합니다. 예:
모두 좋은 저녁입니다. 제가 뭔가 잘못 이해하고 있는 것일 수도 있지만, Bars()의 시작 부분에서 이미 제안된 표준 함수가 왜 적합하지 않은지 완전히 명확하지 않습니다. 나는 항상 그것을 사용하고 문제가 없습니다. 나중에 만날 수 있는 유일한 것은TimeCurrent() 를 사용할 때 "범위를 벗어난 배열" 또는 음수 값이지만 그에 따라 확인해야 합니다. 예:
숫자 32000000000으로 보아 이것도 내 창작물이다. UINT_MAX는 더 짧고 더 단단해 보입니다. ))
사실이 옵션이 더 정확하다는 것이 밝혀졌습니다.
하지만
외적인 차이는 거의 없습니다. 하지만 반면에 상위 버전은 MQL4의 표준 iBarShift 기능을 매우 정확하게 반복합니다.
숫자 32000000000으로 보아 이것도 내 창작물이다. UINT_MAX는 더 짧고 더 단단해 보입니다. ))
사실이 옵션이 더 정확하다는 것이 밝혀졌습니다.
하지만
외적인 차이는 거의 없습니다. 하지만 반면에 상위 버전은 MQL4의 표준 iBarShift 기능을 매우 정확하게 반복합니다.
그래서 어디에서 멈췄습니까? 가장 쉬운 것은 무엇입니까?
그래서 어디에서 멈췄습니까? 가장 쉬운 것은 무엇입니까?
지금은 이 옵션 을 보완하고 싶지만 이미 서비스 데스크 구독을 취소한 Bars 기능 정지 버그 를 우회하도록 하고 있습니다.
이 버그의 핵심은 Bars 함수의 start_time 과 stop_time 이 모두 같은 막대 안에 있거나 미래에 있는 경우(0 막대 오른쪽), 이 함수는 10초 이상 멈춥니다.
아마도 조금 후에 나는 여전히 정확한 더 빠른 버전을 만들 것이지만 더 복잡합니다.
나는 다른 길을 택하기로 했다.
iBarShift를 다시 실행하지 않고 버그가 있는 Bars 기능 을 다시 실행합니다.
또한, 새로운 iBars 기능은 동결 버그를 우회할 뿐만 아니라 원래 Bars보다 더 빠르게 작동합니다.
이 기능은 다른 알고리즘을 사용할 수 있으며 기존 알고리즘이 더 빠르게 작동합니다.
나는 시간이 필요할 뿐입니다. 나는 다음 날까지 이것을 할 수 없을 것이다.
나는 다른 길을 택하기로 했다.
iBarShift를 다시 실행하지 않고 버그가 있는 Bars 기능 을 다시 실행합니다.
또한 새로운 iBars 기능은 동결 버그를 우회할 뿐만 아니라 원래 Bars보다 더 빠르게 작동합니다.
이 기능은 다른 알고리즘을 사용할 수 있으며 기존 알고리즘이 더 빠르게 작동합니다.
나는 시간이 필요할 뿐입니다. 다음 날까지 이 작업을 수행할 수 없습니다.
아주 잘! 나는 그것을 기대하고있어!
내가 한 모든 분석에서 결론은 이것이 iBarShift 기능과 완전히 유사하다는 것을 암시합니다.
가장 정확하고 동시에 가장 빠르고 가장 간단하고 짧은 알고리즘입니다.
아름답지만 뭔가 혼란스러운 ...
테스트해야 함)
iBars 기능이 매우 성가신 것으로 판명되었지만 MQ가 중단 버그를 수정할 때까지 일반 막대 대신 사용하는 것이 좋습니다.
iBar는 논리적으로 0을 반환해야 할 때 멈춥니다. 일반적으로 10초 이상 반환합니다. MQL4에는 그러한 버그가 없습니다.
대부분의 작업에서 iBars는 버그를 우회할 뿐만 아니라 이전 값을 보존하는 알고리즘 덕분에 가능한 한 Bars 및 SeriesInfoInteger 함수 를 사용하지 않으려고 하기 때문에 일반 Bars보다 빠르게 작동합니다.
이 기능을 위아래로 모두 테스트했습니다. 바를 완전히 반복하는 것 같습니다.
어쩌면 더 우아하게 할 수 있습니다. 욕망이 있는 사람 - 환영합니다. 오류를 찾으면 수정하겠습니다.
그래서...
그러면 iBarsShift 기능의 완전한 아날로그는 다음과 같이 보일 것입니다.
그리고 대부분의 경우에 사용되는 정확한 마지막 매개변수가 없는 옵션은 다음과 같습니다.
@Alain Verleyen의 내장 Bars 및 iBarShift 기능과 비교한 iBars 기능의 성능을 보여주는 표시기
함수 실행 시간(마이크로초)입니다.