그러나 시간 프레임뿐만 아니라 여러 틱으로 역사를 형성하지 않는 이유는 무엇입니까? 10, 100, 500, 1000 등을 말합니다. 이 경우 볼륨 조정 타임라인입니다. 볼륨이 분석에 매우 중요한 지표라는 것을 부인하지 않을 것입니다. 매우 명확해집니다. 또한, 사용자가 필요하다고 생각하는 틱 수 또는 시간 표시기에 따라 사용자가 직접 이력을 작성할 수 있는 가능성을 제공하는 것이 가능합니다. 축적된 데이터는 포럼에서 교환할 수 있습니다. 누가 무엇을 저장했는지. 프로그래밍 방식으로 하는 것이 어렵지 않다고 생각합니다. 누락된 데이터를 보충하기 위해(터미널이 꺼져 있음) 짧은 기간(예: 1-3일) 동안 서버에 틱 기록 을 저장할 수 있습니다.
분명히 개발자는 사이트에 큰 글자로 된 비문을 못 박으면 됩니다. "진드기가 없고 없을 것입니다! 진드기에 대한 토론과 브로커에 대한 토론이 포럼에서 제거됩니다!" :o))) 그렇지 않으면 모든 것이 매주 원을 그리게 됩니다. 진드기를 보관해야 한다는 구체적인 증거도 없이 괴로워하는 사람들의 말만...
당신이 말하는 진드기에 대해 더 구체적으로 말할 수 있습니까? 실제 계정 의 틱 이력을 보는 것은 흥미로울 것입니다. 그리고 문헌에서 그러한 열정은 그래프의 축소로 작성되어 실제로 고문을 실제로 던지기 전에 10 번 생각할 것입니다. 게다가 브로커가 실제 진드기의 아카이브를 업로드하는 것을 본 적이 없습니다. 그래서 정말로 숨길 것이 있는지 궁금하십니까?
여기 있습니다. 나는 구체적으로 - 분 내 시뮬레이션에 심각한 불일치가 있음을 증명합니다. 특히 10점. 데이터를 가져오고, 조사를 수행하고, 모든 데이터(이력 파일 포함)를 게시하고 우리를 벽으로 밀어붙이기만 하면 됩니다.
1분 시뮬레이션 내 오차는 1~2점 이내라고 주장합니다. 그리고 이 오류는 절대적으로 수용 가능하고 정상적인 것입니다.
레나트 , 나는 당신에게 완전히 동의하기 때문에 그것을 증명하지 않을 것입니다. 또한, 나는 누구에게도 벽을 밀지 않을 것입니다. 나는 테스터 의 진드기 시뮬레이션이 나에게 완벽하게 적합하다고 선언합니다. 나는 그에 대해 전혀 불만이 없습니다.
동시에 나는 다시 반복합니다. 틱 기록의 필요성은 테스터의 시뮬레이션과 아무 관련이 없습니다.
그리고 그 필요성을 정당화하기 위해 내가 말할 수 있는 모든 것을 위에서 말했습니다.
솔란더 , 사용자가 개발자에게 자신의 요구 사항을 적극적으로 설명하지 않고 지속적으로 설명하지 않으면 사용자와 개발자 모두 고통을 겪을 것입니다. 개발자가 인내심과 이해심을 나타내지 않고 동시에 제품 개발에 대한 전략적 접근 방식을 나타내지 않으면 사용자와 개발자 모두 고통을 겪을 것입니다. 나는 당신이 이것을 이해하기를 바랍니다.
여기 있습니다. 나는 구체적으로 - 분 내 시뮬레이션에 심각한 불일치가 있음을 증명합니다. ... 1분 시뮬레이션 내 오차는 1~2점 이내라고 주장합니다. 그리고 이 오류는 절대적으로 수용 가능하고 정상적인 것입니다.
당신은 항상 시장의 PRICE 측면에 대해 이야기합니다. 여기에서 의심할 여지 없이 성공했으며 PRICE 모델링의 오류는 무시할 수 있습니다. 그러나 견적 흐름에는 특히 뉴스 이동 기간 동안 시뮬레이션에 의해 완전히 파괴되는 다른 매개변수가 있습니다. 제 생각에는 모든 시간 프레임과 시간 프레임뿐만 아니라 틱 프레임(예: 촛불에 10틱)과 kagi 차트 및 tic-tac-toe를 얻을 수 있는 틱 기록 만 필요합니다. 저것들. 시간 분할과 관련된 모든 인위적인 제한이 제거됩니다.
제 생각에는 모든 시간 프레임과 시간 프레임뿐만 아니라 틱 프레임(예: 촛불에 10개의 틱)과 kagi 차트 및 tic-tac-toe를 얻을 수 있는 틱 기록만 필요합니다. 저것들. 시간 분할과 관련된 모든 인위적인 제한이 제거됩니다.
이에 절대적으로 동의합니다. 개발자는 틱 프레임이 시간 프레임과 동일한 권리를 갖고 있음을 증명해야 합니까? 상당한 기간 동안 많은 양의 데이터로 인해 틱 기록만 저장하는 데 어려움이 있는 경우 현재 시간 프레임에서 수행되는 것처럼 최소한 고정된 틱 프레임을 저장할 수 있습니다. 내 욕망은 테스터, 고문 및 기타 말도 안되는 소리와 아무 관련이 없습니다. 저는 약 1년 동안 실제 계정 으로 거래를 했으며 수동으로만 합니다. 모든 것이 간단합니다. 가격 변동이 있으면 이익으로 거래하는 것이 기본이며 가격이 한 곳에서 앞뒤로 매달려 있으면 고문이 도움이되지 않습니다. 그리고 컴퓨터가 스스로 결정하게하십시오 - 신이 금지합니다. 그래서 틱 프레임이 가격 움직임을 더 시각적으로 반영한다고 생각하고 개인적으로 작업하는 것이 더 편리합니다. 실제로 구현하기가 어렵습니까?
기록을 양질의 분으로 저장하는 것이 최적인 것 같습니다. 그것들로부터 어떤 프레임이든 만들 수 있습니다(적어도 시간, 최소한 tic-tac-toe, 최소한 다른 방법으로 접습니다). 정말 중요한 것은 주요 MT4 차트의 축이 균일 하다는 것입니다. 일정한 시간 간격으로 수집된 데이터에 대해 계산되는 ... 일정한 간격이 아닌 다른 이유로 회의록을 수집하기 위해 오프라인 차트를 다뤄야 하는데 이건 분명히 해결될듯 MT의 다음 버전에서만 ... 그러면 최소한 즉시 그림을 볼 수 있습니다. 파도에서 (나는 파도가 있기 때문에 엘리엇을 쓰지 않지만 파도의 구조가 큰 질문입니까?). 일반적으로 나는 QUALITY 분의 기본 이야기입니다.
여기 문제가 있습니다. 아무도 시간이 가장 좋은 변수가 아니라고 주장할 것입니다. 어떤 가격을 책정해야 하는지, 가격은 주로 거래 횟수와 거래량에 따라 달라지며 틱 거래량 은 의 특정 기능입니다. 이러한 매개변수(잘 또는 그에 가까운 것). 따라서 연구의 경우 시간 프레임보다 틱 프레임이 더 중요합니다. 어쨌든, 이 스레드에서 말한 사람들에 따라 단순히 추정한다면, 그것을 원하는 사람들의 절대 다수입니다.
내 자신의 터미널을 만들었 다면 =))), 나는 이것을 할 것입니다: 나는 서버에 틱만 저장하고 다운로드만 허용합니다. 클라이언트에서 틱에서 필요한 모든 TimeFrames(및 TickFrames)를 만듭니다.
따라서 1년 동안 모든 TF의 차트를 얻으려면 35.7Mb의 트래픽이 필요합니다(Yurixx의 계산에서). 이제 MT4에서 동일한 기간 동안의 모든 시간대에 대한 다운로드 기록에는 약 20.763MB(15.71 + 3.142 + 1.047 + 0.524 + 0.262 + 0.065 + 0.011 + 0.002)가 필요합니다.
요약하자면, 틱 기록 의 장점 은 다음과 같습니다. - 사용자 자신이 필요한 TF를 결정하고 항상 스스로 구축할 수 있습니다. 틱 기록의 단점 : - 소비된 트래픽 양이 1.7배 증가합니다(모든 TF 다운로드와 비교할 때). - 프로세서의 부하가 증가합니다(필요한 TF를 지속적으로 구성하기 위해).
분명히 개발자는 사이트에 큰 글자로 된 비문을 못 박으면 됩니다. "진드기가 없고 없을 것입니다! 진드기에 대한 토론과 브로커에 대한 토론이 포럼에서 제거됩니다!" :o))) 그렇지 않으면 모든 것이 매주 원을 그리게 됩니다. 진드기를 보관해야 한다는 구체적인 증거도 없이 괴로워하는 사람들의 말만...
실제 계정 의 틱 이력을 보는 것은 흥미로울 것입니다.
그리고 문헌에서 그러한 열정은 그래프의 축소로 작성되어 실제로 고문을 실제로 던지기 전에 10 번 생각할 것입니다.
게다가 브로커가 실제 진드기의 아카이브를 업로드하는 것을 본 적이 없습니다. 그래서 정말로 숨길 것이 있는지 궁금하십니까?
1분 시뮬레이션 내 오차는 1~2점 이내라고 주장합니다. 그리고 이 오류는 절대적으로 수용 가능하고 정상적인 것입니다.
레나트 ,
나는 당신에게 완전히 동의하기 때문에 그것을 증명하지 않을 것입니다. 또한, 나는 누구에게도 벽을 밀지 않을 것입니다. 나는 테스터 의 진드기 시뮬레이션이 나에게 완벽하게 적합하다고 선언합니다. 나는 그에 대해 전혀 불만이 없습니다.
동시에 나는 다시 반복합니다.
틱 기록의 필요성은 테스터의 시뮬레이션과 아무 관련이 없습니다.
그리고 그 필요성을 정당화하기 위해 내가 말할 수 있는 모든 것을 위에서 말했습니다.
솔란더 ,
사용자가 개발자에게 자신의 요구 사항을 적극적으로 설명하지 않고 지속적으로 설명하지 않으면 사용자와 개발자 모두 고통을 겪을 것입니다.
개발자가 인내심과 이해심을 나타내지 않고 동시에 제품 개발에 대한 전략적 접근 방식을 나타내지 않으면 사용자와 개발자 모두 고통을 겪을 것입니다.
나는 당신이 이것을 이해하기를 바랍니다.
MQL4와 호환됩니까, 아니면 개념적으로 새로운 것입니까?
이에 대한 API가 있습니까?
1분 시뮬레이션 내 오차는 1~2점 이내라고 주장합니다. 그리고 이 오류는 절대적으로 수용 가능하고 정상적인 것입니다.
당신은 항상 시장의 PRICE 측면에 대해 이야기합니다. 여기에서 의심할 여지 없이 성공했으며 PRICE 모델링의 오류는 무시할 수 있습니다.
그러나 견적 흐름에는 특히 뉴스 이동 기간 동안 시뮬레이션에 의해 완전히 파괴되는 다른 매개변수가 있습니다.
제 생각에는 모든 시간 프레임과 시간 프레임뿐만 아니라 틱 프레임(예: 촛불에 10틱)과 kagi 차트 및 tic-tac-toe를 얻을 수 있는 틱 기록 만 필요합니다.
저것들. 시간 분할과 관련된 모든 인위적인 제한이 제거됩니다.
저것들. 시간 분할과 관련된 모든 인위적인 제한이 제거됩니다.
이에 절대적으로 동의합니다. 개발자는 틱 프레임이 시간 프레임과 동일한 권리를 갖고 있음을 증명해야 합니까? 상당한 기간 동안 많은 양의 데이터로 인해 틱 기록만 저장하는 데 어려움이 있는 경우 현재 시간 프레임에서 수행되는 것처럼 최소한 고정된 틱 프레임을 저장할 수 있습니다. 내 욕망은 테스터, 고문 및 기타 말도 안되는 소리와 아무 관련이 없습니다. 저는 약 1년 동안 실제 계정 으로 거래를 했으며 수동으로만 합니다. 모든 것이 간단합니다. 가격 변동이 있으면 이익으로 거래하는 것이 기본이며 가격이 한 곳에서 앞뒤로 매달려 있으면 고문이 도움이되지 않습니다. 그리고 컴퓨터가 스스로 결정하게하십시오 - 신이 금지합니다.
그래서 틱 프레임이 가격 움직임을 더 시각적으로 반영한다고 생각하고 개인적으로 작업하는 것이 더 편리합니다. 실제로 구현하기가 어렵습니까?
그것들로부터 어떤 프레임이든 만들 수 있습니다(적어도 시간, 최소한 tic-tac-toe, 최소한
다른 방법으로 접습니다).
정말 중요한 것은 주요 MT4 차트의 축이 균일 하다는 것입니다.
일정한 시간 간격으로 수집된 데이터에 대해 계산되는 ...
일정한 간격이 아닌 다른 이유로 회의록을 수집하기 위해
오프라인 차트를 다뤄야 하는데 이건 분명히 해결될듯
MT의 다음 버전에서만 ... 그러면 최소한 즉시 그림을 볼 수 있습니다.
파도에서 (나는 파도가 있기 때문에 엘리엇을 쓰지 않지만 파도의 구조가 큰 질문입니까?).
일반적으로 나는 QUALITY 분의 기본 이야기입니다.
어쨌든, 이 스레드에서 말한 사람들에 따라 단순히 추정한다면, 그것을 원하는 사람들의 절대 다수입니다.
나는 서버에 틱만 저장하고 다운로드만 허용합니다.
클라이언트에서 틱에서 필요한 모든 TimeFrames(및 TickFrames)를 만듭니다.
따라서 1년 동안 모든 TF의 차트를 얻으려면 35.7Mb의 트래픽이 필요합니다(Yurixx의 계산에서).
이제 MT4에서 동일한 기간 동안의 모든 시간대에 대한 다운로드 기록에는 약 20.763MB(15.71 + 3.142 + 1.047 + 0.524 + 0.262 + 0.065 + 0.011 + 0.002)가 필요합니다.
요약하자면, 틱 기록 의 장점 은 다음과 같습니다.
- 사용자 자신이 필요한 TF를 결정하고 항상 스스로 구축할 수 있습니다.
틱 기록의 단점 :
- 소비된 트래픽 양이 1.7배 증가합니다(모든 TF 다운로드와 비교할 때).
- 프로세서의 부하가 증가합니다(필요한 TF를 지속적으로 구성하기 위해).
나만의 단말기를 만든 다면 먼저 신중히 생각해볼텐데....