여기에서 1993년 이후의 분(사실 1999년까지 분 대신 일이 있음)이 압축 해제되고 바로 사용할 수 있는 형식으로 231MB를 차지하는 것을 볼 수 있습니다. 동시에 근처 시계는 4MB만 차지합니다.
52바이트에 4,400,000개의 막대를 곱하면 약 230MB의 값을 얻게 됩니다. 하나의 작업 버퍼(이중)가 있는 간단한 이동 평균 표시기를 이러한 기록에 적용하려면 4,400,000 * 8 = 35MB의 메모리가 필요합니다.
거래자가 터미널 설정에서 "창당 최대 막대"를 설정할 때 그는 "작업을 위해 지정된 수의 막대를 메모리에 로드하지 마십시오"라고 명시적으로 말합니다. 분의 전체 기록이 로드되면(M1 차트에서 작업이 진행 중임) 여러 무거운 다중 버퍼 표시기가 중첩되고 전문가가 사용되므로 메모리 비용이 상당할 수 있습니다. 그리고 당신은 "나는 하나의 창으로 작업하고 있습니다. 500개의 막대가 표시되므로 나머지는 언로드할 수 있습니다."를 셀 수 없습니다. 지표, 전문가 등을 언로드하는 것은 불가능합니다. 이 데이터에 대해 살고 작업합니다.
그래서, 그것은 내가 최근에 M1에서 1996년까지 올라가서 더 오래된 시간 프레임의 막대로 대체된 분 막대를 자세히 볼 수 없었던 이유를 의미합니까? 그렇다면 "잘못된 기록 다운로드"의 이유는 특히 MQL 스크립트 다운로드의 비뚤어진 시도에 대해 이야기하는 것이 아니라 터미널에서 직접 이야기하기 때문에 사라집니다. 여기서 프로그래머로서 나는 아무 관련이 없습니다. 그것은 전혀 단순한 사용자로 남아 있습니다(필요한 경우가 아니면 사용자로서 최대 막대 수에 대해 더 큰 값을 설정해야 합니까?).
지표의 실시간 재계산과 관련하여... 예측 가능했습니다. 저는 물을 붓지 않았습니다. 하지만 여기에 개발자 자신의 추가 확인이 있습니다. 지표를 계산하려면 현재 사용자의 "뒤에 있는" 막대를 고려해야 합니다. 그러나 이것이 시각적 측면뿐만 아니라 의미가 있다면 여기에서 상황의 변화에 대한 지표의 틱별 재계산과 모순되는 것은 없지만 전체가 아니라 조각, 섹터별로 기록 섹터의 작은 메모리 버퍼를 점유한 다음 하위 결과를 하나의 결과로 붙이고 표시기 판독값의 최종 형성. 그렇지 않습니까? 그리고 다중 스레드(스트림에서 - 각 하위 섹터에 대해)인 경우 일반적으로 아름다움이 있을 것이며 눈을 깜박일 시간이 없을 것입니다. 글쎄, LIFO - 이것은 적어도 사용자에게 차트의 보이는 부분을 표시하는 것과 관련이 있지만, 구성할 수학 접근 방식에 따라 데이터 조각의 하위 계산에도 유용할 수 있습니다.
어떤 식으로든 이 모든 것이 "단일 소스 데이터 - 여러 차트"라는 멋진 개념을 방해해서는 안 됩니다.
그리고 연구에 필요한 모든 역사를 기억으로 몰아넣고 이 모든 것을 매 틱마다, 심지어 한 스트림에서 계산하는 것은 결국 정결하지 않습니다!
...흠! 그러나 멀티스레딩은 계산을 위해 RAM 세그먼트를 좁히는 아이디어를 즉시 죽입니다. 그런 다음 계산을 위한 하위 섹터 수 - 너무 많은 스레드 - 점유된 메모리가 그만큼 곱해지는 것으로 나타났습니다(빌드를 연결하고 컴파일할 때 이 모든 것이 어떻게든 교활하게 자동으로 최적화되지 않는 한 ... 그러나 나는 하지 않습니다 심지어 즉시 무언가를 하십시오. 이것이 스크립트 및 표시기에서 수행되는 바와 같이 막대의 MQL 계산에 관한 것인지 아니면 그러한 계산이 터미널 코드 수준에서 구현되어야 하는지 알아낼 것입니다. 결과적으로 동일한 2GB가 분명히 실행됩니다. 멀티 스레딩은 속도, 순서 - 메모리 소비를 줄이는 데 좋습니다.
차트에 겹쳐진 각 그래픽 개체에 생성 날짜와 시간(+ 마지막 수정도 가능)을 속성에 제공하는 것이 매우 유용하다고 생각합니다. 때로는 아는 것이 매우 중요합니다. 그렇지 않으면 때로는 무언가를 그리고 다른 비슷한 것 옆에 있으면 주저합니다 ... - 그리고 당신은 당신이 무엇을 그린지, 얼마나 오래되었는지 기억할 수 없습니다 ... 그리고 현재로서는 의심스러운 관련성이 있고 일정을 내리기 위해 제거해야 합니다. 실제로, 실제 시장 상황에 따르면 모든 것이 아니며 관련성 측면에서 항상 명확하지 않습니다. 여기 있습니다.
오? .. S.I. Ozhegov의 러시아어 설명 사전에서 문자 o가있는이 단어 ... 형사 조사를 수행하고 싶습니다. 문자 o가있는 단어는 4 번째 열에 개발자를 숨깁니다. "객체 목록" ... 국가적으로 중요한 그런 것이 있으면 어떻게 무지에 잠이 들 수 있습니까? .. 글쎄, 그것은 어떤 식 으로든 뽑히지 않습니다. 나는 이미 그녀와 저것과 끌과 끌을 가지고 있습니다 ...
이것은 개체가 위치한 창의 번호입니다. 터미널 도움말에서(도움말 읽기, 모든 것이 있습니다):
В данном окне отображается список всех объектов, наложенных в данный момент на график. Наложенные объекты представлены в виде таблицы со следующими полями:
객체— 객체 유형.
이름- 개체의 이름입니다. 이 이름은 개체가 중첩된 차트의 기간, 개체 유형 및 각 개체에 자동으로 할당되는 고유 식별자로 구성됩니다. 이 이름은 개체의 속성에서 변경할 수 있습니다.
설명— 개체에 대한 설명입니다. 또한 개체의 속성에서 변경할 수 있습니다.
창— 개체가 겹쳐지는 창의 번호입니다. 0은 차트의 메인 창을 의미하고, 그 이상의 숫자는 위에서 아래로 지표 하위 창의 인덱스 번호를 의미합니다.
"개체" 필드에 체크 표시를 하면 이 개체가 차트에서 강조 표시됩니다. "표시" 버튼을 클릭하면 그래프가 선택한 개체로 이동합니다. "속성" 버튼을 누르면 선택한 개체의 속성 편집이 진행됩니다. "삭제" 버튼을 클릭하면 선택한 개체가 삭제됩니다. 단축키 Ctrl+A를 사용하여 모든 개체를 선택할 수 있습니다.
일부 시간대에 간격 영역에 수직 전선이 나타나는 것에 대해 의견을 말하고 이를 제거할 필요가 없다고 생각하는 경우 결정을 정당화하십시오. 더 넓은 양초로 동일한 아티팩트가 나타납니다. 내가 틀릴 수도 있지만 비슷한 일이 MT4에서 발생했지만 매우 드물게 발생했습니다. MT4에서는 또 다른 이상한 효과가 여전히 자주 발생합니다. 작은 기간에 차트의 수직 중단이 있지만 전면 자체는 아니지만 역사의 깊이 어딘가에 있습니다. 이 경우 주말이나 주말이 아니라 시각적으로 관찰할 수 있는 차이입니다. 즉, 갭이 없었으나 갭이 관찰되었다. 잘못된 다운로드로 인해 기록의 중요하지 않은 일부가 "삼켜졌을" 수도 있고 이유가 다를 수도 있습니다.
Documentation이 있는 경우, 기능 설명 등의 마지막에 작성해 주십시오. 요청 시, 이 기능에 대해 엄격하게 열리는 포럼이 많은 도움이 될 것입니다. 때로는 설명을 읽지만 조언자의 원하는 디자인에 대한 조치나 영향이 끝까지 완전히 명확하지 않고 시간 손실이 시작됩니다. 포럼에서 누군가가 이미 이 기능을 접했을 수 있습니다. 그리고 무엇인지 명확하지 않은 경우 아래에 귀하가 읽은 코드 베이스와 동일합니다 !!!! 뭐라고!!!! 많은 분들이 필요로 하시는 것 같아요!
여기에서 1993년 이후의 분(사실 1999년까지 분 대신 일이 있음)이 압축 해제되고 바로 사용할 수 있는 형식으로 231MB를 차지하는 것을 볼 수 있습니다. 동시에 근처 시계는 4MB만 차지합니다.
52바이트에 4,400,000개의 막대를 곱하면 약 230MB의 값을 얻게 됩니다. 하나의 작업 버퍼(이중)가 있는 간단한 이동 평균 표시기를 이러한 기록에 적용하려면 4,400,000 * 8 = 35MB의 메모리가 필요합니다.
거래자가 터미널 설정에서 "창당 최대 막대"를 설정할 때 그는 "작업을 위해 지정된 수의 막대를 메모리에 로드하지 마십시오"라고 명시적으로 말합니다. 분의 전체 기록이 로드되면(M1 차트에서 작업이 진행 중임) 여러 무거운 다중 버퍼 표시기가 중첩되고 전문가가 사용되므로 메모리 비용이 상당할 수 있습니다. 그리고 당신은 "나는 하나의 창으로 작업하고 있습니다. 500개의 막대가 표시되므로 나머지는 언로드할 수 있습니다."를 셀 수 없습니다. 지표, 전문가 등을 언로드하는 것은 불가능합니다. 이 데이터에 대해 살고 작업합니다.
그래서, 그것은 내가 최근에 M1에서 1996년까지 올라가서 더 오래된 시간 프레임의 막대로 대체된 분 막대를 자세히 볼 수 없었던 이유를 의미합니까? 그렇다면 "잘못된 기록 다운로드"의 이유는 특히 MQL 스크립트 다운로드의 비뚤어진 시도에 대해 이야기하는 것이 아니라 터미널에서 직접 이야기하기 때문에 사라집니다. 여기서 프로그래머로서 나는 아무 관련이 없습니다. 그것은 전혀 단순한 사용자로 남아 있습니다(필요한 경우가 아니면 사용자로서 최대 막대 수에 대해 더 큰 값을 설정해야 합니까?).
지표의 실시간 재계산과 관련하여... 예측 가능했습니다. 저는 물을 붓지 않았습니다. 하지만 여기에 개발자 자신의 추가 확인이 있습니다. 지표를 계산하려면 현재 사용자의 "뒤에 있는" 막대를 고려해야 합니다. 그러나 이것이 시각적 측면뿐만 아니라 의미가 있다면 여기에서 상황의 변화에 대한 지표의 틱별 재계산과 모순되는 것은 없지만 전체가 아니라 조각, 섹터별로 기록 섹터의 작은 메모리 버퍼를 점유한 다음 하위 결과를 하나의 결과로 붙이고 표시기 판독값의 최종 형성. 그렇지 않습니까? 그리고 다중 스레드(스트림에서 - 각 하위 섹터에 대해)인 경우 일반적으로 아름다움이 있을 것이며 눈을 깜박일 시간이 없을 것입니다. 글쎄, LIFO - 이것은 적어도 사용자에게 차트의 보이는 부분을 표시하는 것과 관련이 있지만, 구성할 수학 접근 방식에 따라 데이터 조각의 하위 계산에도 유용할 수 있습니다.
어떤 식으로든 이 모든 것이 "단일 소스 데이터 - 여러 차트"라는 멋진 개념을 방해해서는 안 됩니다.
그리고 연구에 필요한 모든 역사를 기억으로 몰아넣고 이 모든 것을 매 틱마다, 심지어 한 스트림에서 계산하는 것은 결국 정결하지 않습니다!
...흠! 그러나 멀티스레딩은 계산을 위해 RAM 세그먼트를 좁히는 아이디어를 즉시 죽입니다. 그런 다음 계산을 위한 하위 섹터 수 - 너무 많은 스레드 - 점유된 메모리가 그만큼 곱해지는 것으로 나타났습니다(빌드를 연결하고 컴파일할 때 이 모든 것이 어떻게든 교활하게 자동으로 최적화되지 않는 한 ... 그러나 나는 하지 않습니다 심지어 즉시 무언가를 하십시오. 이것이 스크립트 및 표시기에서 수행되는 바와 같이 막대의 MQL 계산에 관한 것인지 아니면 그러한 계산이 터미널 코드 수준에서 구현되어야 하는지 알아낼 것입니다. 결과적으로 동일한 2GB가 분명히 실행됩니다. 멀티 스레딩은 속도, 순서 - 메모리 소비를 줄이는 데 좋습니다.
뭔가 잘못 이해했다면 저를 수정할 수 있습니다.
내장 지표에 "지표 기간 선택" 옵션이 있으면 좋을 것입니다. 기본값은 현재 기간입니다. 모든 지표를 직접 만들 수 있다는 것은 분명하지만 TM5를 이제 막 사용하기 시작한 사람들도 있습니다. 예, 이 옵션은 전혀 문제가 되지 않습니다.
일간 차트에 표시되는 30분의 5주기 이동 평균 을 어떻게 상상하시나요???
데일리 캔들 안의 squigggle 같은 건가요?
일간 차트에 표시되는 30분의 5주기 이동 평균을 어떻게 상상하시나요???
데일리 캔들 안의 squigggle 같은 건가요?
차트에 겹쳐진 각 그래픽 개체에 생성 날짜와 시간(+ 마지막 수정도 가능)을 속성에 제공하는 것이 매우 유용하다고 생각합니다. 때로는 아는 것이 매우 중요합니다. 그렇지 않으면 때로는 무언가를 그리고 다른 비슷한 것 옆에 있으면 주저합니다 ... - 그리고 당신은 당신이 무엇을 그린지, 얼마나 오래되었는지 기억할 수 없습니다 ... 그리고 현재로서는 의심스러운 관련성이 있고 일정을 내리기 위해 제거해야 합니다. 실제로, 실제 시장 상황에 따르면 모든 것이 아니며 관련성 측면에서 항상 명확하지 않습니다. 여기 있습니다.
사소한 일이지만 좋습니다.
오? .. S.I. Ozhegov의 러시아어 설명 사전에서 문자 o가있는이 단어 ... 형사 조사를 수행하고 싶습니다. 문자 o가있는 단어는 4 번째 열에 개발자를 숨깁니다. "객체 목록" ... 국가적으로 중요한 그런 것이 있으면 어떻게 무지에 잠이 들 수 있습니까? .. 글쎄, 그것은 어떤 식 으로든 뽑히지 않습니다. 나는 이미 그녀와 저것과 끌과 끌을 가지고 있습니다 ...
이것은 개체가 위치한 창의 번호입니다. 터미널 도움말에서(도움말 읽기, 모든 것이 있습니다):
В данном окне отображается список всех объектов, наложенных в данный момент на график. Наложенные объекты представлены в виде таблицы со следующими полями:
"개체" 필드에 체크 표시를 하면 이 개체가 차트에서 강조 표시됩니다. "표시" 버튼을 클릭하면 그래프가 선택한 개체로 이동합니다. "속성" 버튼을 누르면 선택한 개체의 속성 편집이 진행됩니다. "삭제" 버튼을 클릭하면 선택한 개체가 삭제됩니다. 단축키 Ctrl+A를 사용하여 모든 개체를 선택할 수 있습니다.
이것은 개체가 위치한 창의 번호입니다.
A, 분명하다. 고맙습니다. 하위 창, 즉 하나의 차트의 공통 창 내에서 표시기 창(차트에 직접 중첩되지 않음)이라고 하는 것이 더 정확할 것입니다.
"List of Objects" 창에 대해... 음, "모양 기억"을 사용하여 전통적으로 만드는 것이 논리적일 수 있습니다. 그래서 마우스 버튼을 놓을 때 구분 기호가 제자리에 고정되도록 합니까?
일부 시간대에 간격 영역에 수직 전선이 나타나는 것에 대해 의견을 말하고 이를 제거할 필요가 없다고 생각하는 경우 결정을 정당화하십시오. 더 넓은 양초로 동일한 아티팩트가 나타납니다. 내가 틀릴 수도 있지만 비슷한 일이 MT4에서 발생했지만 매우 드물게 발생했습니다. MT4에서는 또 다른 이상한 효과가 여전히 자주 발생합니다. 작은 기간에 차트의 수직 중단이 있지만 전면 자체는 아니지만 역사의 깊이 어딘가에 있습니다. 이 경우 주말이나 주말이 아니라 시각적으로 관찰할 수 있는 차이입니다. 즉, 갭이 없었으나 갭이 관찰되었다. 잘못된 다운로드로 인해 기록의 중요하지 않은 일부가 "삼켜졌을" 수도 있고 이유가 다를 수도 있습니다.
고맙습니다.
소원!!!! 메모!!!!!
Documentation이 있는 경우, 기능 설명 등의 마지막에 작성해 주십시오. 요청 시, 이 기능에 대해 엄격하게 열리는 포럼이 많은 도움이 될 것입니다. 때로는 설명을 읽지만 조언자의 원하는 디자인에 대한 조치나 영향이 끝까지 완전히 명확하지 않고 시간 손실이 시작됩니다. 포럼에서 누군가가 이미 이 기능을 접했을 수 있습니다. 그리고 무엇인지 명확하지 않은 경우 아래에 귀하가 읽은 코드 베이스와 동일합니다 !!!! 뭐라고!!!! 많은 분들이 필요로 하시는 것 같아요!