이것은 흥미로운 질문입니다. 무엇이 정확하다고 간주되는지, 역사 수정 이전 또는 이후에 있었던 것입니다. 수정된 막대로 돌아가지 않으면 표시기는 이력이 수정되지 않은 것처럼 계속 작동합니다. hrenfx는 이 문제에 대해 정확히 이 태도를 가지고 있습니다. 그는 오래된 이야기가 옳다고 생각하지만 당신은 그 반대입니다.
옵션 없이 표준 prev_calculated만 사용해야 한다는 의견도 있습니다. 표시기가 무거우면 시작 시 계산되는 막대 수를 제한하십시오. 나머지는 탬버린으로 춤을 추고 있으며 결과는 의심 스럽습니다.
이것은 흥미로운 질문입니다. 무엇이 정확하다고 간주되는지, 역사 수정 이전 또는 이후에 있었던 것입니다. 수정된 막대로 돌아가지 않으면 표시기는 이력이 수정되지 않은 것처럼 계속 작동합니다. hrenfx는 이 문제에 대해 정확히 이 태도를 가지고 있습니다. 그는 오래된 이야기가 옳다고 생각하지만 당신은 그 반대입니다.
옵션 없이 표준 prev_calculated만 사용해야 한다는 의견도 있습니다. 표시기가 무거우면 시작 시 계산되는 막대 수를 제한하십시오. 나머지는 탬버린으로 춤을 추고 있으며 결과는 의심 스럽습니다.
모든 사람은 무엇이 옳고 그른지 스스로 결정합니다. ZigZag의 경우 위에서 설명한 상황은 완전히 치명적입니다. MA의 경우 값에 0.0001의 편차가 있습니다...
의견이 종종 부과될 수 있습니다(그게 틀렸다고 말하는 것이 아닙니다).
일반적으로 나는 여기서 논쟁을 끝낼 것을 제안합니다. 이론적 고려 사항은 아무 것도 이끌어 낼 수 없습니다 ..
그건 그렇고, MT5는 실시간으로 기록 기반의 무결성에 대한 매우 효과적이고 즉각적인 제어를 사용하여 prev_counted를 0으로 재설정하는 빈도를 높입니다. 이 카운터를 올바르게 고려하지 않고 자신의 최적화에 참여하면 실제 작업에서 많은 문제를 잡을 수 있습니다. 분 이력 업데이트는 서버 자체에서 터미널로 즉시 전달됩니다.
Renat : 그건 그렇고, MT5는 실시간으로 기록 기반의 무결성에 대한 매우 효과적이고 즉각적인 제어를 사용하여 prev_counted를 0으로 재설정하는 빈도를 높입니다. 이 카운터를 올바르게 고려하지 않고 자신의 최적화에 참여하면 실제 작업에서 많은 문제를 잡을 수 있습니다. 분 이력 업데이트는 서버 자체에서 터미널로 즉시 전달됩니다.
요점은 테스터에 있지 않습니다. 다시 한 번! 테스터 가 아닌 실제 상황에서 히스토리가 재개되고 연결이 끊어집니다.
실제 조건에서 표시기가 재설정되고 다시 계산되면 문제가 없습니다.
또 다른 질문이 생겼습니다. 대부분의 사람들이 여기서 할 일은 없겠죠? 그들은 앉아서 mql5에서 터미널의 일반 기능을 다시 작성합니다. 아마도 곧 누군가 mql5에서 전체 터미널을 작성할 것입니다.
실제 조건에서 표시기가 재설정되고 다시 계산되면 문제가 없습니다.
또 다른 질문이 생겼습니다. 대부분의 사람들이 여기서 할 일은 없겠죠? 그들은 앉아서 mql5에서 터미널의 일반 기능을 다시 작성합니다. 아마도 곧 누군가 mql5에서 전체 터미널을 작성할 것입니다.
물론 걱정할 것은 없습니다. 하나의 터미널에 100개의 ZUP이 걸려 있으면(저는 예시일 뿐입니다) 괜찮습니다...
같은 질문이 나왔습니다. 모두 자신의 종탑에서만 이야기하는 것을 좋아합니다. 왜?
여기에서 둘 이상의 지표가 사용됩니다.
일반 함수 IndicatorCount의 영향은 그에게 치명적입니다(개인적으로 확인했습니다). 그리고 클래스로 구현하면 통신 중단은 일반적으로 자주색입니다.
PS 하나의 MA의 경우 확실히 걱정할 필요가 없습니다.
물론 괜찮습니다. 하나의 터미널에 100개의 ZUP이 걸려 있으면(저는 예시일 뿐입니다) 괜찮습니다...
같은 질문이 나왔습니다. 모두 자신의 종탑에서만 이야기하는 것을 좋아합니다. 왜?
누군가는 항상 자신이 할 수 있는 것보다 더 많은 것을 원합니다. 하지만 왜 그렇게 많은가?
다섯 줄의 코드로 표시기 재설정 문제를 해결할 수 있습니다. 첫 번째 막대의 시간을 기억하십시오. 변경된 경우 전체 재계산이 필요합니다. 마지막 막대의 번호를 기억하고 재설정할 경우 이 막대에서 계속 다시 계산하면 됩니다.
내 종탑에서 나는 논쟁을 뒷받침하지 않고 내 종탑이 더 정확하다고 말하는 것을 두려워하지 않습니다.
누군가는 항상 그들이 할 수 있는 것보다 더 많은 것을 원합니다. 하지만 왜 그렇게 많은가?
다섯 줄의 코드로 표시기 재설정 문제를 해결할 수 있습니다. 첫 번째 막대의 시간을 기억하십시오. 변경된 경우 전체 재계산이 필요합니다. 마지막 막대의 번호를 기억하고 재설정할 경우 이 막대에서 계속 다시 계산하면 됩니다.
내 종탑에서 나는 논쟁을 뒷받침하지 않고 내 종탑이 더 정확하다고 말하는 것을 두려워하지 않습니다.
너무 자신만만하지 마세요. 듣기만 하는 것이 아니라 다른 사람의 말을 듣기도 합니다.
중간에 이야기가 바뀔 수 있고 접근 방식은 지옥에 갈 것입니다. 이에 대해 레나타에게 물어보세요.
방금 내 팁에서 수정된 MT4의 IndicatorCounted() 버그로 인해 올바르게 작성된 표시기 조차 스크랩으로 전송되었습니다(특히 소규모 시간 프레임의 경우 ZigZag).
이 문제에 대한 귀하의 접근 방식은 말할 것도 없습니다.
이 상황에서 당신이 완전히 틀렸기 때문에 나는 당신과 논쟁조차하지 않을 것입니다.
너무 자신만만하지 마세요. 듣기만 하는 것이 아니라 다른 사람의 말을 듣기도 합니다.
중간에 이야기가 바뀔 수 있고 접근 방식은 지옥에 갈 것입니다. 이에 대해 레나트에게 물어보세요.
방금 내 팁에서 수정된 MT4의 IndicatorCounted() 버그로 인해 올바르게 작성된 표시기 조차 스크랩으로 전송되었습니다(특히 소규모 시간 프레임의 경우 ZigZag).
이 상황에서 당신이 완전히 틀렸기 때문에 나는 당신과 논쟁조차하지 않을 것입니다.
재설정 시 막대 수가 증가했지만 막대의 시간이 변경되지 않았는지 또는 둘 이상의 막대가 추가되었는지 여부를 몇 가지 더 확인합니다.
자신감은 그 반대야 여기서 특히 자신 있는 건 너야 이미 MQ보다 자신이 멋있다고 생각하는 세 번째 사람이다.
재설정 시 막대 수가 증가했지만 막대의 시간이 변경되지 않았는지 또는 둘 이상의 막대가 추가되었는지 여부를 몇 가지 더 확인합니다.
자신감은 그 반대야 여기서 특히 자신 있는 건 너야 이미 MQ보다 자신이 멋있다고 생각하는 세 번째 사람이다.
무엇을 확인합니까? 상황. 이전 막대에 새 눈금이 나타납니다. 변경된 사항은 없습니다. 총 막대 수도 마지막 막대의 여는 시간도 마찬가지지만 동시에
마지막 30개 막대가 다시 작성되었습니다 (시작/종가, 최대값, 최소값, 약간이지만 변경됨).
알고리즘으로 무엇을 할 것인가? 아무것도! 이 상황에서는 작동하지 않습니다. 그리고 표시기는 완전히 올바르지 않습니다!
최신 빌드 이전에 MT4에 있었던 내용 - 70%의 경우 이 상황에 어떤 식으로든 반응하지 않았습니다.
그러나 이 문제를 분석한 후 모든 것이 수정되었습니다. 여기 Stingo는 이에 대해 썼습니다. https://www.mql5.com/ru/forum/132422
나는 내가 다른 사람들보다 낫다고 생각하지 않는다. 반대로 저는 MT4와 MT5의 모든 버그를 수정하는 데 적극적으로 돕습니다. MetaQuotes 담당자에게 문의하세요.
그리고 일부 메커니즘이 원하는대로 구현되지 않는다는 사실 - 모든 사람을 기쁘게 할 수는 없습니다 ....
이것은 흥미로운 질문입니다. 무엇이 정확하다고 간주되는지, 역사 수정 이전 또는 이후에 있었던 것입니다. 수정된 막대로 돌아가지 않으면 표시기는 이력이 수정되지 않은 것처럼 계속 작동합니다. hrenfx는 이 문제에 대해 정확히 이 태도를 가지고 있습니다. 그는 오래된 이야기가 옳다고 생각하지만 당신은 그 반대입니다.
옵션 없이 표준 prev_calculated만 사용해야 한다는 의견도 있습니다. 표시기가 무거우면 시작 시 계산되는 막대 수를 제한하십시오. 나머지는 탬버린으로 춤을 추고 있으며 결과는 의심 스럽습니다.
이것은 흥미로운 질문입니다. 무엇이 정확하다고 간주되는지, 역사 수정 이전 또는 이후에 있었던 것입니다. 수정된 막대로 돌아가지 않으면 표시기는 이력이 수정되지 않은 것처럼 계속 작동합니다. hrenfx는 이 문제에 대해 정확히 이 태도를 가지고 있습니다. 그는 오래된 이야기가 옳다고 생각하지만 당신은 그 반대입니다.
옵션 없이 표준 prev_calculated만 사용해야 한다는 의견도 있습니다. 표시기가 무거우면 시작 시 계산되는 막대 수를 제한하십시오. 나머지는 탬버린으로 춤을 추고 있으며 결과는 의심 스럽습니다.
모든 사람은 무엇이 옳고 그른지 스스로 결정합니다. ZigZag의 경우 위에서 설명한 상황은 완전히 치명적입니다. MA의 경우 값에 0.0001의 편차가 있습니다...
의견이 종종 부과될 수 있습니다(그게 틀렸다고 말하는 것이 아닙니다).
일반적으로 나는 여기서 논쟁을 끝낼 것을 제안합니다. 이론적 고려 사항은 아무 것도 이끌어 낼 수 없습니다 ..
테스터에서 지표 계산의 사용자 정의 최적화는 완벽하게 작동하지만 불쾌한 기록 이동과 잘못된 계산이 터미널에 나타날 수 있습니다.
그건 그렇고, MT5는 실시간으로 기록 기반의 무결성에 대한 매우 효과적이고 즉각적인 제어를 사용하여 prev_counted를 0으로 재설정하는 빈도를 높입니다. 이 카운터를 올바르게 고려하지 않고 자신의 최적화에 참여하면 실제 작업에서 많은 문제를 잡을 수 있습니다. 분 이력 업데이트는 서버 자체에서 터미널로 즉시 전달됩니다.
테스터에서 지표 계산의 사용자 정의 최적화는 완벽하게 작동하지만 불쾌한 기록 이동과 잘못된 계산이 터미널에 나타날 수 있습니다.
그리고 나는 그것에 대해 이야기하고 있습니다.
아마도 prev_counted를 0이 아닌 수정되지 않은 첫 번째 값으로 재설정하는 방법에 대해 여전히 생각하고 있습니까?