찻주전자의 질문 - 페이지 204

 

호기심에 hcc 히스토리 파일을 찾아봤다.

hcc 바이너리 내부의 데이터 레코드 행은 FileSeek(handle,15333, SEEK_SET ) 로 시작하고 다음과 같이 보입니다.

4바이트 정수 구분 기호

4바이트 정수 날짜/시간

8바이트 더블 오픈

8바이트 더블 하이

8바이트 더블 로우

8바이트 더블 닫기

1 또는 2바이트 정수 TickVolume

1 또는 2바이트 int 스프레드

최대 4바이트 볼륨일 수 있습니다.

또한 마지막 두 개 또는 세 개의 int 길이는 내가 이해하는 한 첫 번째 구분 기호에서 결정됩니다. 어떻게 이해하지? 1 또는 그 이상의 바이트가 마지막 2-3 int로 결정되는 방법을 알려주시겠습니까?

 
ANG3110 :

제발 말해줘...

내가 추측했다고 생각합니다. 구분 기호에는 16진수 코드의 데이터 읽기 구조가 포함되어 있습니다. Type Separator=18385028, 최하위 비트 4888811부터 16번째, 즉 4byte, 8byte.... 1byte.

그런 것 같습니까?

추신: 이것은 파일을 읽는 방법입니다. 189바이트를 건너뛸 필요가 있는 날에만 가능합니다.

이제 개발자가 이러한 파일을 공개하지 않는 이유를 이해합니다. 단순히 서버와의 동기화 문제가 아니라, 실제 "Woe from Wit"처럼 파일을 구축하고 정리하는 구조로 인해 비난을 받을까 두려운 것 같다. Aski 인색함을 추가하고 동기화되지 않은 모든 종류의 재보험을 위해 전체 원자력 선박 "Lenin"이 쌓여있었습니다. 개인적으로 이 모든 변태들은 어쩐지 이해할 수 없고 슬프다.

 
ANG3110 :
이제 개발자가 이러한 파일을 공개하지 않는 이유를 이해합니다. 단순히 서버와의 동기화 문제가 아니라, 실제 "Woe from Wit"처럼 파일을 구축하고 정리하는 구조로 인해 비난을 받을까 두려운 것 같다. Aski 인색함을 추가하고 동기화되지 않은 모든 종류의 재보험을 위해 전체 원자력 선박 "Lenin"이 쌓여있었습니다. 개인적으로 이 모든 변태들은 어쩐지 이해할 수 없고 슬프다.

*.HCC 파일은 압축된 데이터 블록이므로 직접 읽기에 적합하지 않습니다.

이 파일은 /cache 하위 디렉토리에 있는 압축 해제된 작업 시간 프레임을 생성하기 위한 초기 데이터 역할을 합니다.

 
Renat :

*.HCC 파일은 압축된 데이터 블록이므로 직접 읽기에 적합하지 않습니다.

이 파일은 /cache 하위 디렉토리에 있는 압축 해제된 작업 시간 프레임을 생성하기 위한 초기 데이터 역할을 합니다.

레나트. 그리고 왜 그러한 복잡성이 보상을 받았습니까? 그게 정당합니까? 저는 프로그래머도 아니고 뭔가 잘못 이해하고 있을지도 모르지만, 기록의 순서를 보면 소름이 돋습니다. 자신의 작업에 편리한가?

물론 실제로 hcc 파일을 덮어쓸 가능성에 대해 살펴보았습니다. 그러나 그것들의 복잡성을 보면, 점점 더 뼈 속으로 분해되는 것이 지겹습니다. 이제 FXCM 견적이 데모에 있습니다. 저는 찾고 있습니다. 하지만 웬일인지 이야기는 10 월에만 있습니다. 커미션이있는 마크 업없이 만 계정이 있습니다. 나는 한 번 API를 통해 수년 동안 TS2 분으로 펌핑했으며 또한 Ask를 사용했습니다. 테스트가 더 현실적이도록 MT5에서 구현하고 싶었습니다. 하지만 지금은 왠지 소름 돋습니다. 개발자가 hcc 파일의 전체 구조를 제공하지 않으면 스크립트를 사용하여 사용 가능한 기록 파일에서 요청하여 실제 데이터를 읽고 이전 방식으로 MT4에서 테스트를 수행해야 합니다. 그건 그렇고, FXOpen은 MT4에서 바로 Asks로 역사를 제공합니다. 엄청난. 테스터에 넣을 수 없다는 것이 유감입니다. 그러나 최소한 스크립트는 테스트할 수 있습니다.

 
ANG3110 :

나는 호기심에 hcc 기록 파일을 보려고 노력했습니다.

hcc 바이너리 내부의 데이터 레코드 줄은 FileSeek(handle,15333, SEEK_SET )로 시작하는 것으로 나타났습니다.

이 처음 15333바이트에 무엇이 들어 있는지 이해하셨나요?

ANG3110 :

내가 추측했다고 생각합니다. 구분 기호에는 16진수 코드의 데이터 읽기 구조가 포함되어 있습니다. Type Separator=18385028, 최하위 비트 4888811부터 16번째, 즉 4byte, 8byte.... 1byte.
그런 것 같습니까?

흠, 그런 것 같습니다. 파일은 블록별로 읽고 지정된 구분 기호에 따라 블록 크기가 달라지는 것으로 나타났습니다.

추신: 이것은 파일을 읽는 방법입니다. 189바이트를 건너뛸 필요가 있는 날에만 가능합니다.

이것도 hcc인가요?

나는 하루가 실제로 "모자"로 시작한다는 것을 알아차렸습니다. 기호 등의 이름이 포함되어 있습니다. 아마도 이 일일 블록에 포함된 데이터에 따라 이 헤더에 일부 정량적 정보가 입력되었을 것입니다.


그리고 왜 그러한 복잡성이 보상을 받았습니까? 그게 정당합니까?
100% 정당합니다. 전송된 데이터의 양을 저장하고 저장합니다.


추신

자신의 의사록을 만드는 것이 매우 흥미롭기 때문에 주제를 삭제하지 않습니다. 물론 다음 번에 서버와 동기화하는 동안 터미널이 덮어쓰지 않는 한.
 
불행히도 hcc 파일은 변경할 수 없습니다. 동기화 중에 불가피하게 덮어쓰게 됩니다.

우리의 압축 형식은 매우 효율적이며, 압축 형식이 없으면 네트워크 트래픽이 몇 배나 더 많을 것입니다.
 
러시아어가 아닌 Windows에서 작업하고 MetaEditor-a 언어는 러시아어로 설정되어 있지만 도움말(F1)을 호출하면 영어로 나옵니다. 도움말이 러시아어로 표시되도록 다른 곳에서 러시아어로 변경해야 할 수도 있습니다. 나는 러시아 Windows에서 집에 앉아 있고 모든 것이 정상입니다.
 
paladin800 :
러시아어가 아닌 Windows에서 작업하고 MetaEditor-a 언어는 러시아어로 설정되어 있지만 도움말(F1)을 호출하면 영어로 나옵니다. 도움말이 러시아어로 표시되도록 다른 곳에서 러시아어로 변경해야 할 수도 있습니다. 나는 러시아 Windows에서 집에 앉아 있고 모든 것이 정상입니다.
그리고 카탈로그를 보면 디렉토리의 러시아어 파일이 있습니까?
 
Yedelkin :
그리고 카탈로그를 보면 디렉토리의 러시아어 파일이 있습니까?
올바른 방향으로 내 생각을 지적해 주셔서 감사합니다. "mql5.chm"(영문) 파일이 있습니다. 삭제하고 사이트에서 "mql5_russian.chm"을 다운로드하고 MetaEditor를 켠 다음 F1 키를 누르고 러시아어로 도움말을 확인했습니다.
 
paladin800 :
러시아어가 아닌 Windows에서 작업하고 MetaEditor-a 언어는 러시아어로 설정되어 있지만 도움말(F1)을 호출하면 영어로 나옵니다. 도움말이 러시아어로 표시되도록 다른 곳에서 러시아어로 변경해야 할 수도 있습니다. 나는 러시아 Windows에서 집에 앉아 있고 모든 것이 정상입니다.

MetaEditor에서 언어를 변경한 후 다시 로드하셨습니까?

확인하겠습니다.