서비스 데스크: 게으름, 자폐증 또는 실수를 인정하지 않으려는 경향이 있습니까? 네이티브가 아닌 촛대로 차트를 보완합니다. - 페이지 7

 
220Volt :
무슨 근거로 주장하는 겁니까? 당신은 개발자입니까? 그렇지 않은 경우 "IMHO"에 서명하십시오.

이것은 IMHO가 아니라 개발자의 정보입니다.

어쨌든 당신의 질문은 무엇입니까?

 
Urain :

문제를 소유하지 않은 사람과 논의하기가 어렵습니다. 모든 것이 트롤링에 빠지게 됩니다.

좋아요, 막대 사이에 2분이 있으면 어떻게 될까요?

그리고 3분이면 어떻게?

주말 방학이라면?

평일인데 공휴일이라면?

다시 말하지만, MQ의 역사를 보지 마십시오. 현실적입니다. 거래 기록은 그렇게 깊지도 않고 품질도 높지 않습니다(MQ가 이상적이지는 않지만 다른 거래의 모델로 작동할 것입니다).

막대 사이의 분 시간대가 1분 이상인 경우 이는 다른 시간대의 막대이므로 == 1분 조건의 첫 번째 막대가 표시되는 즉시 다음 막대로 이동합니다. 모두 계산을 시작할 수 있는 막대를 찾았습니다.
 
pusheax :
막대 사이의 분 시간대가 1분 이상인 경우 이는 다른 시간대의 막대이므로 == 1분 조건의 첫 번째 막대가 표시되는 즉시 다음 막대로 이동합니다. 모두 계산을 시작할 수 있는 막대를 찾았습니다.

붐, 오류, 컴퓨터의 스파크,

막대 사이에 1분 이상이면 일부 막대에 눈금이 없고 누락된 막대가 있습니다.

그리고 M1의 시작점도 아니고 무엇도 아닙니다.

트롤할 필요가 없습니다. 저는 수년 동안 MQL5로 프로그래밍해 왔습니다. 시간 프레임으로 첫 번째 막대를 찾는 알고리즘은 다소 복잡하고 비효율적입니다. 백만 막대를 거치는 것보다 MQ가 히스토리 파일 자체의 접착 지점에 대한 정보를 보호하고 요청 시 14마이크로초 만에 발행하는 것이 더 쉽습니다. 978,853 bar에서 접착 지점을 찾습니다.

 
Urain :

붐, 오류, 컴퓨터의 스파크,

막대 사이에 1분 이상이면 일부 막대에 눈금이 없고 누락된 막대가 있습니다.

그리고 M1의 시작점도 아니고 무엇도 아닙니다.

트롤할 필요가 없습니다. 저는 수년 동안 MQL5로 프로그래밍해 왔습니다. 시간 프레임으로 첫 번째 막대를 찾는 알고리즘은 다소 복잡하고 비효율적입니다. 백만 막대를 거치는 것보다 MQ가 히스토리 파일 자체의 접착 지점에 대한 정보를 보호하고 요청 시 14마이크로초 만에 발행하는 것이 더 쉽습니다. 978,853 bar에서 접착 지점을 찾습니다.

그리고 이 문제를 어떻게 해결했습니까? 이제 겨우 1년이 지났습니다.

이 문제를 2년 전에 풀었는데 지금은 자세히 기억나지 않지만 어떻게든 막대 사이의 시간을 비교할 수 있었습니다.

 
pusheax :

그리고 이 문제를 어떻게 해결했습니까? 이제 겨우 1년이 지났습니다.

이 문제를 2년 전에 풀었는데 지금은 자세히 기억나지 않지만 어떻게든 막대 사이의 시간을 비교할 수 있었습니다.

나는 어리석게도 날짜부터 계산의 시작을 매개변수에 넣고 사용자가 자신이 임명할 날짜를 알아내도록 했습니다.

각자 알아서 결정을 하지만 정상적인 해결 방법이 있는 사람은 아무도 없습니다. MQ가 갑자기 해결할 수 없는 상황을 만들어 놓았기 때문입니다.

추신 그러나 이것은 또한 목발입니다. 지표에서 지표를 구축하는 것은 문제가 있기 때문에 이 정보를 다른 칠면조로 전송하려면 실제로 계산 된 막대의 수 를 저장할 가짜 버퍼를 만들어야 합니다.

 
sergeev :

이것은 IMHO가 아니라 개발자의 정보입니다.

어쨌든 당신의 질문은 무엇입니까?

질문을 하지 않는 것 같았습니다.
 
다음 또는 다음과 같이 될 것입니다.
Renat : 내가 알기로는 누군가가 의도적으로 "몇 분 안에 다른 것이 있을 수 있다"는 생각으로 히스테리를 일으키게 한다.

또는 다음과 같이:

레나트 :
특히 각 브로커가 사용할 기록을 스스로 결정하기 때문에 문제가 없습니다. 원한다면 조금 더 짧지만 깨끗한 M1을 방송하게 해주세요. 1999년 이전의 역사를 사용할 필요는 없습니다.

연습만이 보여줄 ...

Renat 당신은 당신의 MT4가 프로그래머와 사용자 모두에게 완전히 개방된 환경이라는 것을 이해하고 있습니다. - 저는 .hst 파일에 대한 액세스 및 터미널에서 기록 데이터 내보내기/가져오기에 대해 이야기하고 있습니다. .hcc 설명 및 가져오기 기록 데이터가 없습니다. 확실히, 이 접근 방식을 사용하면 사용자는 "다른 것"을 가질 수 있습니다.

역사의 질을 통제하는 메커니즘을 제공하다

 
IgorM :
다음 또는 다음과 같이 될 것입니다.

또는 다음과 같이:

연습만이 보여줄 ...

Renat 당신은 당신의 MT4가 프로그래머와 사용자 모두에게 완전히 개방된 환경이라는 것을 이해하고 있습니다. - 저는 .hst 파일에 대한 액세스 및 터미널에서 기록 데이터 내보내기/가져오기에 대해 이야기하고 있습니다. .hcc 설명 및 가져오기 기록 데이터가 없습니다. 확실히, 이 접근 방식을 사용하면 사용자는 "다른 것"을 가질 수 있습니다.

역사의 질을 통제하는 메커니즘을 제공하다

나는 "이력 품질 관리 메커니즘"에 동의합니다. 테스트 중 이력의 모든 구멍이 이렇게 생겼고, 이 전체 기간 동안 동일한 막대가 여러 번 복사되고 때로는 이것이 매우 긴 기간이기 때문입니다.
 
komposter :

이것은 홍수 이전 연도에 대한 인용문의 세부사항에 관한 것이 아닙니다. 아무도 전쟁 전 틱을 요구하지 않습니다.

우리는 차트 표시의 구현과 시계열 작업을 위한 해당 기능의 작동에 대해 이야기하고 있습니다.

레나트 :
Komposter, 지난 10-12년 이내의 시간으로 작업하고 1999년보다 오래된 시간이 중요한 척하지 마십시오.

문제가 없고 1999년보다 오래된 날짜가 존재하기 때문에 더 깊은 역사를 볼 수 있습니다.

특히 각 브로커가 사용할 기록을 스스로 결정하기 때문에 문제가 없습니다. 원한다면 조금 더 짧지만 깨끗한 M1을 방송하게 해주세요. 1999년 이전의 역사를 사용할 필요는 없습니다.

쓰여진 것을 읽고 이해하는 능력은 결코 당신의 강점이 아닙니다. Chukchi는 독자가 아니라 Chukchi는 작가입니다 (c)

나는 자폭한다.

 
sergeev :


- 아무도 MQL에 기능을 추가하여 1분과 1일을 분석하지 않습니다. 일반적으로 어떻게 하는지 명확하지 않기 때문입니다.

불분명?

옵션 1) 히스토리 파일에 추가 매개변수 Base TF 추가 - 막대가 실제로 분이면 0, 예를 들어 1시간과 같이 분이 없으면 매개변수 = 60, 막대가 매일이면 매개변수 = 1440.

a) 차트 로딩 시 이를 확인하여 non-native bar 등의 표시를 금지한다. seriesinfointeger 에 대한 최신 정보 ...

b) 한 번 확인하고 모든 스티칭 포인트를 별도로 기록 (결국 히스토리는 어디에도 가지 않을 것입니다)

옵션 2) 스티칭 포인트에 대한 정보만 저장합니다(공간을 절약하기 위해, 비록 우리 시대에는 옵션 1이 주석을 기록하지 않을 것이라고 생각하지만)

옵션 3) 누락된 분 막대를 추가합니다(분 기록 시작 후 - 즉, 주말 및 구멍만 있음). 예를 들어 음수 값을 지정한 다음 다중도 및 예를 들어 시간 i 막대로 작업합니다. i + 1이 1분 이상이면 스티칭 포인트를 찾습니다. 하지만 이 옵션은 모든 지표의 알고리즘을 다시 작성해야 하고 차트가 Zhanna Aguazarova처럼 추악해지기 때문에 가장 어리석습니다.

가장 수용 가능한 IMHO는 옵션 1입니다. 변경된 사항은 없으며 약간만 추가되었습니다.