따라서 거래 방향이 있든 없든 모든 데이터 피드는 먹을 수 있습니다. 이것은 거래소 실행을 위한 전략 테스터 의 문제를 해결할 것입니다. 이는 주식 상품의 틱 히스토리 구조를 확장할 수 있음을 의미합니다. 틱 히스토리의 구조를 확장하여 전략 테스터에서 거래소 실행을 구성하는 것이 가능합니다. 우리는 주식 실제 테스터가 필요합니다!
오류는 정확히 무엇입니까? 제 생각에는 제안 및 입찰과 전혀 일치하지 않는 화면에 있는 것과 같은 거래의 잘못된 렌더링인 이 문제를 해결할 것 같습니다. 그건 그렇고, 나는 TsLab에서 오랫동안 동일한 렌더링 문제를 관찰했는데, 이러한 현상은 서로 다른 데이터 채널 때문인 것 같습니다. 거래는 자체 소켓에서 진행되고 다른 소켓에서 제안/입찰됩니다. 거래는 제안/입찰 라인에 있어야 하며 다른 것은 없어야 합니다. 그냥 현지 비교
(Last == Ask ? TICK_FLAG_BUY : TICK_FLAG_SELL )
두 데이터 채널, 과거 거래 및 제안/입찰을 동기화하고 귀하가 언급한 이 결함을 제거할 수 있습니다.
N/A 카운터 거래의 불확실한 상태도 있습니다. 그들을 위해 플래그의 상태도 고려해야 합니다.
CME 도구에서 확인했습니다. N/A 카운터 딜은 제안/입찰에 의해 도출되지 않습니다. 그러나 그들은 스프레드(녹색 원) 안에 그려져 있는데, 맞습니다. 나머지 거래는 엄격하게 제안/입찰에 의해 이루어집니다. Mos가 있는 악기가 있습니다. 거래소, 아마도 이것은 스프레드에 속하지 않는 카운터 거래이지만 어떤 이유로 스프레드 외부에 있으며 이는 정확하지 않습니다. 이것은 카운터 트랜잭션이 아니라 방향이 있는 지시된 트랜잭션임을 의미합니다. 그리고 다른 논의에서 알 수 있듯이 MT5 단말기의 오더북에는 모스에 대한 카운터 오더가 표시되지 않습니다. 교환. 아마도 이것은 과거 거래의 잘못된 렌더링의 문제일 수 있습니다.
[in] Количество запрашиваемых тиков. Если параметры from и count не указаны, то в массив ticks_array[] будут записаны все доступные последние тики, но не более 2000. Первый вызов CopyTicks() инициирует синхронизацию базы тиков, хранящихся на жёстком диске по данному символу. Если тиков в локальной базе не хватает, то недостающие тики...
CopyTicks(...) 함수를 사용하여 사용자 정의 기호에서 틱을 복사할 때 MQLTick 구조에서 TICK_FLAG_BUY, TICK_FLAG_SELL 플래그의 손실을 찾았습니다.
심볼 RTS-6.20에서 올해의 틱을 CSV 파일로 내보냈습니다. RTS-6.20에서 복사하여 MyRTS-6.20 기호를 만들었습니다. 이 CSV 파일에서 틱을 로드했습니다. 중복이 있습니다. 그의 일정은 모든 것이 괜찮습니다.
그리고 여기 CopyTicks(...)가 있습니다...
fxsaber 스크립트 사용
CopyTicks(...) 함수를 사용하여 사용자 정의 기호에서 틱을 복사할 때 MQLTick 구조에서 TICK_FLAG_BUY, TICK_FLAG_SELL 플래그의 손실을 찾았습니다.
심볼 RTS-6.20에서 올해의 틱을 CSV 파일로 내보냈습니다. RTS-6.20에서 복사하여 MyRTS-6.20 기호를 만들었습니다. 이 CSV 파일에서 틱을 로드했습니다. 중복이 있습니다. 그의 일정은 모든 것이 괜찮습니다.
베타 2414에서 수정되었습니다.
이제 CSV로 내보내고 플래그 열과 함께 가져 옵니다.
여전히 멍청한 질문이 있습니다. MT는 틱 데이터 자체를 분석하여 거래 방향(MqlTick.flags에서 BUY/SELL 설정)을 결정합니까, 아니면 데이터 소스에서 거래 방향 을 얻습니까?
여전히 멍청한 질문이 있습니다. MT는 틱 데이터 자체를 분석하여 거래 방향(MqlTick.flags에서 BUY/SELL 설정)을 결정합니까, 아니면 데이터 소스에서 거래 방향 을 얻습니까?
출처에서.
모든 것은 데이터 피드에 따라 달라지며, 자체적으로 플래그를 설정할 수 있습니다.
출처에서.
모든 것은 데이터 피드에 따라 달라지며, 자체적으로 플래그를 설정할 수 있습니다.
소스에 의존하지 않으려면 플래그를 결정하기 위한 로컬 논리를 구성하는 것이 좋습니다.
따라서 거래 방향이 있든 없든 모든 데이터 피드는 먹을 수 있습니다.
이것은 거래소 실행을 위한 전략 테스터 의 문제를 해결할 것입니다.
이는 주식 상품의 틱 히스토리 구조를 확장할 수 있음을 의미합니다.
틱 히스토리의 구조를 확장하여 전략 테스터에서 거래소 실행을 구성하는 것이 가능합니다.
우리는 주식 실제 테스터가 필요합니다!
이런 프로그램 로직으로 하면 오류가 많이 날 것 같아요 >>>
그런 프로그램 논리라면 오류가 많이 날 것 같아요 >>>
오류는 정확히 무엇입니까?
제 생각에는 제안 및 입찰과 전혀 일치하지 않는 화면에 있는 것과 같은 거래의 잘못된 렌더링인 이 문제를 해결할 것 같습니다.
그건 그렇고, 나는 TsLab에서 오랫동안 동일한 렌더링 문제를 관찰했는데, 이러한 현상은 서로 다른 데이터 채널 때문인 것 같습니다.
거래는 자체 소켓에서 진행되고 다른 소켓에서 제안/입찰됩니다. 거래는 제안/입찰 라인에 있어야 하며 다른 것은 없어야 합니다.
그냥 현지 비교
두 데이터 채널, 과거 거래 및 제안/입찰을 동기화하고 귀하가 언급한 이 결함을 제거할 수 있습니다.
N/A 카운터 거래의 불확실한 상태도 있습니다.
그들을 위해 플래그의 상태도 고려해야 합니다.
CME 도구에서 확인했습니다.
N/A 카운터 딜은 제안/입찰에 의해 도출되지 않습니다.
그러나 그들은 스프레드(녹색 원) 안에 그려져 있는데, 맞습니다.
나머지 거래는 엄격하게 제안/입찰에 의해 이루어집니다.
Mos가 있는 악기가 있습니다. 거래소, 아마도 이것은 스프레드에 속하지 않는 카운터 거래이지만 어떤 이유로 스프레드 외부에 있으며 이는 정확하지 않습니다.
이것은 카운터 트랜잭션이 아니라 방향이 있는 지시된 트랜잭션임을 의미합니다.
그리고 다른 논의에서 알 수 있듯이 MT5 단말기의 오더북에는 모스에 대한 카운터 오더가 표시되지 않습니다. 교환.
아마도 이것은 과거 거래의 잘못된 렌더링의 문제일 수 있습니다.
여보세요!! 말해봐, MT5에서 시세 내역을 다운로드 할 수 있습니까? 2일째 정보를 찾고 있지만 찾을 수 없습니다
진드기 얻기:
카피틱
MqlTick 형식의 눈금을 배열로 가져옵니다.
CopyTicksRange
지정된 날짜 범위의 눈금을 배열로 가져옵니다.