MetaDriver : 그런 편지가 있습니다. 그러나 간격(불연속 인용 부호 점프)은 막대 시작 부분뿐만 아니라 언제든지 발생할 수 있습니다. 따라서 정의에 따라 "얇아진" 형식은 죄가 없는 것이 아닙니다. 틱에서만 전체 피드. 그리고 유리의 역사에서 훨씬 더 풍부할 수 있습니다. 나는 그런 타협점을 찾을 때까지 나 자신을 위한 1분 형식을 만들려고 노력하고 있습니다. 나는 아마도 위에서 설명한 대로 그대로 둘 것입니다(Open 없이. {Hi-Lo-Close}만). 모든 단점을 이해합니다. 이것은 테스터를 위한 코딩 버전 중 하나일 뿐입니다. 또한 원시 틱 또는 모든 방법({bid-ask-time} 틱 형식을 유지하면서)으로 인위적으로 얇게 만든 틱에 대한 테스트를 제공합니다.
예, 바는 원래 낮을 위해 만들어졌습니다. 그들에게는 닫고 여는 것이 중요하고 틈이 빈번합니다. 더 작은 tf oc에서는 그 자체로 중요하지 않습니다. 아마도 세션의 시작과 종료가 여전히 역할을 할 수 있지만 확실히 1분 동안은 아닙니다) IMHA
그리고 일반적으로 데이터가 너무 많은 형식은 어떻습니까? 저것들. 이 틱 필터(주어진 형식)의 제한 사항을 결정할 필요가 있습니다. 이 틱 필터를 사용하여 실행할 때 순수한 틱 기록 에서 실행하는 것과 결과가 다르지 않습니다.
간단히 말해서, 단순한 틱 필터 HighBid+LowAsk는 이러한 힙 필터(데이터 양 측면에서)에 비해 정확도가 크게 떨어지지 않는 것 같습니다.
닫기 데이터 - 다중 통화 동기화 제외.
화를 내지 않고 더 작은 TF로 전환하는 것이 더 쉬울 수도 있습니다. 예를 들어, HighBid+LowAsk 형식의 같은 분에 대한 S20은 48바이트만 필요합니다(가격에 대한 4바이트가 지붕을 넘으면 더 적을 수도 있습니다. 제 테스터에서는 long int를 통해 모든 것을 매우 빠르게 수행합니다). 그리고 정확도 측면에서 100%는 88바이트에 대한 분 필터를 수행합니다.
PS Function Error(Freq, DataSize) = Full - Freq * DataSize 는 Freq 가 증가함에 따라 0이 되는 경향이 있습니다.
여기서 오류 는 정보 손실입니다.
전체 - 완전한 시장 정보.
Freq * DataSize - "곱하기" 기능: 주어진 양자화 주파수 Freq 및 양자화 항당 정보 내용( DataSize )이 주어지면 복구할 수 있는 정보의 양.
그런 다음이 겸손 (이것을 조심해야합니다 - 벌거 벗은 비판보다 나쁩니다).
:-)
Borjomi를 마시거나 거기에서 죄를 속죄하기에는 너무 늦었습니다 .. 지옥의 장소는 오랫동안 나를 위해 예약되었습니다.
판단하지 않고 이해하려는 욕망이 내 죄의 가장 중대하다고 생각하지 않습니다. ;)
그런 편지가 있습니다. 그러나 간격(불연속 인용 부호 점프)은 막대 시작 부분뿐만 아니라 언제든지 발생할 수 있습니다. 따라서 정의에 따라 "얇아진" 형식은 죄가 없는 것이 아닙니다. 틱에서만 전체 피드. 그리고 유리의 역사에서 훨씬 더 풍부할 수 있습니다. 나는 그런 타협점을 찾을 때까지 나 자신을 위한 1분 형식을 만들려고 노력하고 있습니다. 나는 아마도 위에서 설명한 대로 그대로 둘 것입니다(Open 없이. {Hi-Lo-Close}만). 모든 단점을 이해합니다. 이것은 테스터를 위한 코딩 버전 중 하나일 뿐입니다. 또한 원시 틱 또는 모든 방법({bid-ask-time} 틱 형식을 유지하면서)으로 인위적으로 얇게 만든 틱에 대한 테스트를 제공합니다.
판단하지 않고 이해하려는 욕망이 내 죄의 가장 중대하다고 생각하지 않습니다. ;)
생각하는 것은 물론 죄의 심각성에 따라 더 강합니다. 동의한다.
잘하셨다니 다행입니다. 그러니 미리 내 옆에 있는 가마솥을 주문하는 것이 좋다. 최소한 즐기자. 잡담의 시간이 영원할 것입니다. 가석방 없음.
;)
MQ 바 M1이 포장을 풀고 보관되어 있습니까?
그런 다음 기록을 가져오는 데 지연이 있지만(작지만 있음) 다시 액세스(예: 캐시에 이미 액세스)가 더 빠릅니다.
분명히 히스토리 파일에서 막대는 동기화 막대의 변경 사항으로 압축 된 형태로 저장됩니다.
따라서 52바이트 수는 압축 해제된 기록 수입니다.
MQ 바 M1이 포장을 풀고 보관되어 있습니까?
그런 다음 기록을 가져오는 데 지연이 발생하지만(작지만 있음) 다시 액세스(예: 캐시에 이미 액세스)가 더 빠릅니다.
분명히 히스토리 파일에서 막대는 동기화 막대의 변경 사항으로 압축 된 형태로 저장됩니다.
따라서 52바이트 수는 압축 해제된 기록 수입니다.
나는 이것에 대해 아무 주장도 하지 않았다. 뿐만 아니라 - 포장이 거기에 있다고 확신합니다. 형식은 공개 도메인에서 선언되지 않았으며 "돌아가기"를 시도하지 않았습니다.
맞습니다. 압축을 푼 형식만 설명했습니다. 문서에서 가져왔습니다.
나는 이것에 대해 아무 주장도 하지 않았다. 뿐만 아니라 - 포장이 거기에 있다고 확신합니다. 형식은 공개 도메인에서 선언되지 않았으며 "돌아가기"를 시도하지 않았습니다.
맞습니다. 압축을 푼 형식만 설명했습니다. 문서에서 가져왔습니다.
맞습니다. 그러나 포장을 푼 현재 형식과 부분적으로 포장된 새 형식을 비교하면서 새 형식이 경제적일 것임을 보여주려고 합니다.
나는 경제를 비교하지 않습니다. 그것은 당신에게 보였습니다. 정보 제공. 절약할 수 없습니다. 압축을 푼 형식은 == 88바이트 {Open, High, Low, Close} 및 == 72바이트 {High, Low, Close}가 더 큽니다.
글쎄요, 돌 때문에 암에 걸리는 것은 아무것도 없었습니다. 52바이트 88 대신 정보 내용을 두 배로 늘리는 것이 좋습니다.
처음부터 hrenfx 는 동일한 것을 제공했습니다.
그리고 일반적으로 데이터가 너무 많은 형식은 어떻습니까? 저것들. 이 틱 필터(주어진 형식)의 제한 사항을 결정할 필요가 있습니다. 이 틱 필터를 사용하여 실행할 때 순수한 틱 기록 에서 실행하는 것과 결과가 다르지 않습니다.
간단히 말해서, 단순한 틱 필터 HighBid+LowAsk는 이러한 힙 필터(데이터 양 측면에서)에 비해 정확도가 크게 떨어지지 않는 것 같습니다.
닫기 데이터 - 다중 통화 동기화 제외.
화를 내지 않고 더 작은 TF로 전환하는 것이 더 쉬울 수도 있습니다. 예를 들어, HighBid+LowAsk 형식의 같은 분에 대한 S20은 48바이트만 필요합니다(가격에 대한 4바이트가 지붕을 넘으면 더 적을 수도 있습니다. 제 테스터에서는 long int를 통해 모든 것을 매우 빠르게 수행합니다). 그리고 정확도 측면에서 100%는 88바이트에 대한 분 필터를 수행합니다.
PS Function Error(Freq, DataSize) = Full - Freq * DataSize 는 Freq 가 증가함에 따라 0이 되는 경향이 있습니다.
여기서 오류 는 정보 손실입니다.
전체 - 완전한 시장 정보.
Freq * DataSize - "곱하기" 기능: 주어진 양자화 주파수 Freq 및 양자화 항당 정보 내용( DataSize )이 주어지면 복구할 수 있는 정보의 양.