이것은 쓸모없는 운동입니다. 당신이 뭔가를 증명할 수 있다 하더라도 그들은 그것을 하지 않을 것입니다.
따옴표 시간이 있는 생생한 예, 명백한 MQ 오류, 고칠 수 있습니까?
입찰가가 오래 전에 변경되었으며 이전 입찰에서 거래가 이루어졌습니다(데이터는 CopyTicksRange() GAZR-12.21 함수에 의해 반환됨)
그것은 실수가 아니다. 이것이 실시간 스트림이 작동하는 방식입니다. 이것은 MetaTrader와 광장이 없는 동안 다른 사이트(예: 지하실)에서 자주 발생합니다. 특히 동시에 시작하는 경우 하나의 견적 패키지가 다른 견적 패키지를 따라잡을 수 있습니다. 다음 사항은 파란색으로 밑줄이 그어져 있습니다.
Last Buy 거래가 27밀리초(Time Diff 필드)에 도달하고 07:43:32.857에 시작하여 Ask 수준이 07:43:32.858에 변경된 것을 알 수 있지만 이에 대한 정보는 25밀리초에 도달했습니다. 우리는 역순으로 변경 사항을 보았습니다. 1) Ask 수준 의 변경 07:43:32.883 2) 마지막 이벤트 07:43:32.884
동일한 변경된 순서로 터미널은 이러한 견적을 받았습니다. 첫 번째 견적이 이미 사용자에게 전송되었으므로 더 이상 주문을 변경할 수 없습니다. 정상적인 터미널은 수신된 따옴표를 필요한 순서로 정렬하기 위해 몇 밀리초의 추가 지연(버퍼 만들기)을 도입하지 않습니다. 히스토리를 기록할 때 추가 정렬이 이미 수행될 수 있습니다.
그것은 실수가 아니다. 이것이 실시간 스트림이 작동하는 방식입니다. 이것은 MetaTrader와 광장이 없는 동안 다른 사이트(예: 지하실)에서 자주 발생합니다. 특히 동시에 시작하는 경우 하나의 견적 패키지가 다른 견적 패키지를 따라잡을 수 있습니다. 다음 사항은 파란색으로 밑줄이 그어져 있습니다.
Last Buy 거래가 27밀리초(Time Diff 필드)에 도달하고 07:43:32.857에 시작하여 Ask 수준이 07:43:32.858에 변경된 것을 알 수 있지만 이에 대한 정보는 25밀리초에 도달했습니다. 우리는 역순으로 변경 사항을 보았습니다. 1) Ask 수준 의 변경 07:43:32.883 2) 마지막 이벤트 07:43:32.884
동일한 변경된 순서로 터미널은 이러한 견적을 받았습니다. 첫 번째 견적이 이미 사용자에게 전송되었으므로 더 이상 주문을 변경할 수 없습니다. 정상적인 터미널은 수신된 따옴표를 필요한 순서로 정렬하기 위해 몇 밀리초의 추가 지연(버퍼 만들기)을 도입하지 않습니다. 히스토리를 기록할 때 추가 정렬이 이미 수행될 수 있습니다.
모두가 귀하의 설명에 동의하지만 빨간색 거래(파란색 원) 전후에 입찰가가 항상 다릅니다 .
청산이란? 제가 알기로는 예를 들어 대체 가능한 거래와 겹쳐서 구매자와 판매자의 균형을 맞추기 위해 경매가 중단됩니다. 그것 의 본질 은 거래 세션 에 대해 수행된 거래 의 설명 에 있습니다 . 그러나 거래 과정에서 여러 거래가 고려되지 않고 잔액이 초과되지 않으면 거래소는 무엇을합니까? 즉, 청산 과정에서 3건의 계약 중 2건이 손실된 것을 계산해 알아냈다. 교환은 무엇을 합니까? 거래량 측면에서 거래 세션의 기록이 변경됩니까? 손가락의 실을 설명할 수 있는 사람이 있습니까?
내가 왜 묻는거야. 최적화 후 아침에 히스토리에 3개의 오류가 있었는데 지우고 나니 오류가 5개로 늘어나서 히스토리를 수정한 것 같습니다. 사실 저는 견적에 의존하는 데이터를 사용하며 기록에 약간의 변화가 있어도 0 막대의 최종 결과가 크게 변경됩니다. 예를 들어 실제 거래량을 사용하는 AD 지표를 계산하고 히스토리의 특정 막대부터 계산을 시작하므로 히스토리에 있는 막대의 볼륨을 1단위 이상 변경하면 그 불일치가 상당할 것입니다. 제로 바에 의해. 그리고 클리어할 때마다 오류는 점점 더 커집니다. 그리고 교환 규칙의 역사를 이해할 수 없거나 어딘가에 비뚤어진 계산이 있습니다. 누구든지 명확하게 설명 할 수 있습니까? 미리 감사드립니다!
이것이 내가 클리어링 메커니즘을 상상하는 방법입니다
즉, MYEX에서는 스프레드를 위해 하루에 두 번 모두의 신발을 신고 신경 쓰지 않습니다.
전체 주문 로그에 대한 월간 구독 비용은 14,500루블입니다.
그리고 1개월 구독이 가능한지는 미정 :)
추가됨
오래전에 했을텐데 MQ가 터미널의 Exchange 부분과 관련해서 동작하기 때문에
이것은 쓸모없는 운동입니다. 당신이 뭔가를 증명할 수 있다 하더라도 그들은 그것을 하지 않을 것입니다.
따옴표 시간이 있는 생생한 예, 명백한 MQ 오류, 고칠 수 있습니까?
입찰가가 오래 전에 변경되었으며 이전 입찰에서 거래가 이루어졌습니다(데이터는 CopyTicksRange() GAZR-12.21 함수에 의해 반환됨)
그것은 실수가 아니다. 이것이 실시간 스트림이 작동하는 방식입니다. 이것은 MetaTrader와 광장이 없는 동안 다른 사이트(예: 지하실)에서 자주 발생합니다. 특히 동시에 시작하는 경우 하나의 견적 패키지가 다른 견적 패키지를 따라잡을 수 있습니다. 다음 사항은 파란색으로 밑줄이 그어져 있습니다.
Last Buy 거래가 27밀리초(Time Diff 필드)에 도달하고 07:43:32.857에 시작하여 Ask 수준이 07:43:32.858에 변경된 것을 알 수 있지만 이에 대한 정보는 25밀리초에 도달했습니다. 우리는 역순으로 변경 사항을 보았습니다. 1) Ask 수준 의 변경 07:43:32.883 2) 마지막 이벤트 07:43:32.884
동일한 변경된 순서로 터미널은 이러한 견적을 받았습니다. 첫 번째 견적이 이미 사용자에게 전송되었으므로 더 이상 주문을 변경할 수 없습니다. 정상적인 터미널은 수신된 따옴표를 필요한 순서로 정렬하기 위해 몇 밀리초의 추가 지연(버퍼 만들기)을 도입하지 않습니다. 히스토리를 기록할 때 추가 정렬이 이미 수행될 수 있습니다.
그것은 실수가 아니다. 이것이 실시간 스트림이 작동하는 방식입니다. 이것은 MetaTrader와 광장이 없는 동안 다른 사이트(예: 지하실)에서 자주 발생합니다. 특히 동시에 시작하는 경우 하나의 견적 패키지가 다른 견적 패키지를 따라잡을 수 있습니다. 다음 사항은 파란색으로 밑줄이 그어져 있습니다.
Last Buy 거래가 27밀리초(Time Diff 필드)에 도달하고 07:43:32.857에 시작하여 Ask 수준이 07:43:32.858에 변경된 것을 알 수 있지만 이에 대한 정보는 25밀리초에 도달했습니다. 우리는 역순으로 변경 사항을 보았습니다. 1) Ask 수준 의 변경 07:43:32.883 2) 마지막 이벤트 07:43:32.884
동일한 변경된 순서로 터미널은 이러한 견적을 받았습니다. 첫 번째 견적이 이미 사용자에게 전송되었으므로 더 이상 주문을 변경할 수 없습니다. 정상적인 터미널은 수신된 따옴표를 필요한 순서로 정렬하기 위해 몇 밀리초의 추가 지연(버퍼 만들기)을 도입하지 않습니다. 히스토리를 기록할 때 추가 정렬이 이미 수행될 수 있습니다.
모두가 귀하의 설명에 동의하지만 빨간색 거래(파란색 원) 전후에 입찰가가 항상 다릅니다 .
모두가 귀하의 설명에 동의하지만 빨간색 거래(파란색 원) 전후에 입찰가가 항상 다릅니다 .
그래, 난 참조. 변경 사항의 차이는 10초 이상입니다. 마지막 판매는 37230에서 37225 사이의 존재하지 않는 가격으로 발생하지만 37224 수준에서 Bid가 변경되지 않습니다. 예, 이것은 Time&Sales가 아닙니다. 이것은 일종의 모방입니다.
글쎄, 내가 무슨 말을 할 수 있습니까? "당신은 거기에 매달려"
동료 환영,
청산이란? 제가 알기로는 예를 들어 대체 가능한 거래와 겹쳐서 구매자와 판매자의 균형을 맞추기 위해 경매가 중단됩니다. 그것 의 본질 은 거래 세션 에 대해 수행된 거래 의 설명 에 있습니다 . 그러나 거래 과정에서 여러 거래가 고려되지 않고 잔액이 초과되지 않으면 거래소는 무엇을합니까? 즉, 청산 과정에서 3건의 계약 중 2건이 손실된 것을 계산해 알아냈다. 교환은 무엇을 합니까? 거래량 측면에서 거래 세션의 기록이 변경됩니까? 손가락의 실을 설명할 수 있는 사람이 있습니까?
내가 왜 묻는거야. 최적화 후 아침에 히스토리에 3개의 오류가 있었는데 지우고 나니 오류가 5개로 늘어나서 히스토리를 수정한 것 같습니다. 사실 저는 견적에 의존하는 데이터를 사용하며 기록에 약간의 변화가 있어도 0 막대의 최종 결과가 크게 변경됩니다. 예를 들어 실제 거래량을 사용하는 AD 지표를 계산하고 히스토리의 특정 막대부터 계산을 시작하므로 히스토리에 있는 막대의 볼륨을 1단위 이상 변경하면 그 불일치가 상당할 것입니다. 제로 바에 의해. 그리고 클리어할 때마다 오류는 점점 더 커집니다. 그리고 교환 규칙의 역사를 이해할 수 없거나 어딘가에 비뚤어진 계산이 있습니다. 누구든지 명확하게 설명 할 수 있습니까? 미리 감사드립니다!
이것이 내가 클리어링 메커니즘을 상상하는 방법입니다
즉, MYEX에서는 스프레드를 위해 하루에 두 번 모두의 신발을 신고 신경 쓰지 않습니다.
또한 지우고 나면 기본적으로 모든 것이 잠금 + .op에 있습니다.
나는 유리에 대해 이야기하고있다.
유리 테스트를 썼고, 그는 또한 계산 검사입니다
결론 - 적어도 다른 전자 시장과 어떻게 든 차별화하기위한 픽션, 롤빵
이것은 belmes가 아니지만 기사에서 가격 책정에 대해 쓰는 한 가지 ......
가격이 어떻게 나오는지 포럼에서 세 번이나 들었습니다.
적어도 누군가는 이해합니다 ;)
이것이 내가 클리어링 메커니즘을 상상하는 방법입니다
즉, MYEX에서는 스프레드를 위해 하루에 두 번 모두의 신발을 신고 신경 쓰지 않습니다.
또한 지우고 나면 기본적으로 모든 것이 잠금 + .op에 있습니다.
아무데도 씌워지지 않습니다.
닫았다가 같은 가격으로 열었습니다. 자산이 루블이면 총 지느러미. 결과는 전혀 변하지 않습니다. (달러인 경우 현재 환율이 다소 영향을 받습니다.)
순전히 기술적인 운영. 자물쇠가 없는 것처럼 퍼짐도 없습니다.
청산 후 귀하는 귀하와 동일한 위치에 있으며 해당 위치의 손익 만 잔액으로 유입됩니다.아무데도 씌워지지 않습니다.
닫았다가 같은 가격으로 열었습니다. 자산이 루블이면 총 지느러미. 결과는 전혀 변하지 않습니다. (달러인 경우 현재 환율이 다소 영향을 받습니다.)
순전히 기술적인 운영. 자물쇠가 없는 것처럼 퍼짐도 없습니다.
청산 후 귀하는 귀하와 동일한 위치 에 있으며 해당 위치의 손익 만 잔액으로 유입됩니다.추가하는 것을 잊었거나 잘못 이해했습니다.
청산 작업으로 인해 모든 사람이 현재 매수/매도로 이동하고 현재 시점의 거래를 요약합니다. babos는 저울에서 떨어지거나 병합됩니다.
그리고 그것은 무엇을 의미합니까?
오 똑같다;;
추가하는 것을 잊었거나 잘못 이해했습니다.
청산 작업으로 인해 모든 사람이 현재 매수/매도로 이동하고 현재 시점의 거래를 요약합니다. babos는 저울에서 떨어지거나 병합됩니다.
그리고 그것은 무엇을 의미합니까?
오 똑같다;;
현재 청산 중인 매도/입찰이 없습니다.
현재 청산 중인 매도/입찰이 없습니다.
그리고 어떤 가격으로 요약됩니까?
종가 기준, 청산 전 (18-44)