다시 말하지만 관련성 문제가 있습니다. 하나의 주문은 항상 최신 상태로 유지됩니다. 나머지 - 가능한 경우. 모든 주문이 최신 상태가 아닐 수 있습니다.
최신 - 얼마입니까?
2개 매수, 입찰 1.2345, SL 1.2344
다음 틱: 입찰가 1.2350, 첫 번째 주문의 SL은 1.2349로 이동하고 두 번째 주문은 1.2344에 유지
틱을 기다리지 않고: 입찰가는 이미 1.2375이고 첫 번째 주문의 SL은 1.2374로 이동하고 두 번째 주문은 여전히 거기에 있습니다.
한 단계 더: 입찰가 1.2376, 첫 번째 주문의 SL은 1.2375로 이동하고 두 번째 주문은 동일하게 유지
가격이 1.2300으로 돌아가면 둘 다(1.2374 및 1.2344)의 SL이 트리거됩니다[계산의 단순화를 위해 가격이 갑자기 1.2300에 도달했다고 가정합시다(그러면 두 정거장 모두 이 수준까지 미끄러졌을 것입니다). EA는 수정하느라 바빴고 이 시점에서 아무것도 할 시간이 없었습니다.]
결과: 첫 번째 주문에 대해 +30 포인트, 두 번째 주문에 대해 +0
내 버전에서는 두 SL이 모두 1.2375로 수정되거나 최악의 경우 1.2374로 수정됩니다. 결과: 두 주문에 대해 +30 포인트.
fxsaber :
나는 당신이 의미하는 바를 이해하고 싶지만 작동하지 않습니다. "대기 시간이 지나면 거래 환경을 업데이트하십시오"라는 원칙에 문제가 있다고 보지 않습니다.
다음 틱: 입찰가 1.2350, 첫 번째 주문의 SL은 1.2349로 이동하고 두 번째 주문은 1.2344에 유지
틱을 기다리지 않고: 입찰가는 이미 1.2375이고 첫 번째 주문의 SL은 1.2374로 이동하고 두 번째 주문은 여전히 거기에 있습니다.
한 단계 더: 입찰가 1.2376, 첫 번째 주문의 SL은 1.2375로 이동하고 두 번째 주문은 동일하게 유지
가격이 1.2300으로 돌아가면 둘 다(1.2374 및 1.2344)의 SL이 트리거됩니다[계산의 단순화를 위해 가격이 갑자기 1.2300에 도달했다고 가정합시다(그러면 두 정거장 모두 이 수준까지 미끄러졌을 것입니다). EA는 수정하느라 바빴고 이 시점에서 아무것도 할 시간이 없었습니다.]
결과: 첫 번째 주문에 대해 +30 포인트, 두 번째 주문에 대해 +0
내 버전에서는 두 SL이 모두 1.2375로 수정되거나 최악의 경우 1.2374로 수정됩니다. 결과: 두 주문에 대해 +30 포인트.
귀하의 예에서 모든 단계에서 TS는 거래 주문 없이 주문이 있어야 할 위치를 알아야 합니다. 저것들. 일반적으로 TS는 주문이 현재 있는 위치에 묶일 수 없습니다. 그녀는 그들이 서 있어야 할 위치를 계산하고 거래 주문을 통해 계산한 것과 거래 환경을 동기화하는 데만 관심이 있습니다.
귀하의 예에서 TS의 결과는 OnTick이 높은 가격에 왔는지 여부에 따라 다릅니다. 그리고 올바른 차량은 바로 그 이전에 있어야 합니다. 그녀는 (심지어 OnTick을 건너뛴 경우에도) 그러한 가격이 있음을 확인했으며, 이는 그녀의 SL이 그에 따라 배치되어야 함을 의미합니다. 그리고 동기화는 100% 일을 할 것입니다.
그리고 왜 계속 두 번째 사람이 서 있다고 말하는지 이해가 되지 않습니다. 동기화 논리가 없어도 버전과 동일한 방식으로 수정됩니다. OnTick은 NewTick 이벤트가 아니라 일반적인 내부 함수로 호출됩니다.
귀하의 예에서 모든 단계에서 TS는 거래 주문 없이 주문이 있어야 할 위치를 알아야 합니다. 저것들. 일반적으로 TS는 주문이 현재 있는 위치에 묶일 수 없습니다. 그녀는 그들이 서 있어야 할 위치를 계산하고 거래 주문을 통해 계산한 것과 거래 환경을 동기화하는 데만 관심이 있습니다.
그녀는 알고 있습니다. 그러나 동기화할 시간이 없습니다. 한 번의 수정이 진행되는 동안 가격은 더 올라가고 새로운 계산된 상태는 첫 번째 주문을 다시 수정하라고 알려줍니다. 그래서 항상.
fxsaber :
귀하의 예에서 TS의 결과는 OnTick이 높은 가격에 왔는지 여부에 따라 다릅니다. 그리고 올바른 차량은 바로 그 이전에 있어야 합니다. 그녀는 (심지어 OnTick을 건너뛴 경우에도) 그러한 가격이 있음을 확인했으며, 이는 그녀의 SL이 그에 따라 배치되어야 함을 의미합니다. 그리고 동기화는 100% 일을 할 것입니다.
의존하지 않습니다(예제에서는 SL 레벨 계산이 없었습니다).
동기화는 작업을 수행하지 않습니다. 시간이 없습니다(위 참조).
fxsaber :
그리고 왜 계속 두 번째 사람이 서 있다고 말하는지 이해가 되지 않습니다. 동기화 논리가 없어도 버전과 동일한 방식으로 수정됩니다. OnTick은 NewTick 이벤트가 아니라 일반적인 내부 함수로 호출됩니다.
평소대로, 나는 그것을 얻었다.
하지만 수정이 진행되는 동안 이미 가격이 변했고, OnTick의 강제 호출은 이미 새 가격으로 작동하고 있는 반면, 2차 주문은 초기 수준을 유지했습니다.
상상해보십시오. 4 대의 트럭이 있습니다. 그들 각각은 A 지점에서 B 지점까지 귀중한 화물을 운반합니다. 경로를 제어해야 합니다. 당신은 무엇을 선호합니까? 매분 - 그들 중 하나와 연결하거나 2분마다 - 그들 모두와 연결하시겠습니까?
두 번째 경우에는 지연 시간이 조금 더 길어지고, 지시할 시간이 없으면 4명 모두 약간 우회해야 할 수도 있습니다. 그러나 일반적으로 트럭 한 대를 가지고 다른 세 대를 잃는 것보다 비즈니스에 더 유리할 것입니다.
+1.
아마도 OOP 접근 방식에서는 새로운 아이디어가 나오지 않았을 것입니다. 주문을 반복하는 주기의 아날로그가 OrderModify를 직접 호출하는 대신 수정 명령을 형성하는 관리자와 같은 어떤 종류의 엔터티에 숨겨져 있을 때(모든 매개변수)를 대기열에 넣은 다음 처리합니다. 요점은 위의 코드에서 단일 루프로 채워진 책임을 환경 분석의 특정 개체와 분석을 기반으로 하는 작업을 수행하는 개체로 나누는 것입니다.
아마도 이 아이디어는 OOP 접근 방식에서 발생하지 않았을 것입니다. 주문을 반복하는 주기의 유사체가 OrderModify를 직접 호출하는 대신 수정 명령(모든 매개변수 포함)을 생성하고 관리자와 같은 일부 엔티티에 숨겨져 있을 때 큐에 넣은 다음 처리됩니다. 요점은 위의 코드에서 단일 루프로 채워진 책임을 환경 분석의 특정 개체와 분석을 기반으로 하는 작업을 수행하는 개체로 나누는 것입니다.
비동기식 주문을 통해서만 이러한 상황을 피할 수 있습니다.
그렇지 않으면 실행할 명령 목록을 통해 계속 루프가 있게 되며, 실제로 이것은 명령을 통한 루프입니다.
대기열이 있는 상황에서만 해당 주문과 관련된 이전의 실행되지 않은 주문을 새로운 주문으로 교체하는 것이 여전히 필요합니다. 그렇지 않으면 대기열이 넘칠 수 있고 대기열의 주문이 만료될 수 있습니다.
가격이 이동하고 각각의 새로운 OnTick 호출에서 목록의 첫 번째인 동일한 주문의 새로운 수정에 대한 조건이 충족될 것입니다. 특히 수정이 5초 동안 지속되는 경우 ;)
다시 말하지만 관련성 문제가 있습니다. 하나의 주문은 항상 최신 상태로 유지됩니다. 나머지 - 가능한 경우. 귀하의 옵션은 모든 주문이 최신 상태가 아니라는 것입니다.
이러한 "백본"은 하나 이상의 주문과 함께 작동하는 Expert Advisor의 논리를 깨뜨릴 것입니다.
한 가지 명령으로 시스템에 아무런 이점도 주지 않고 나머지는 망친다면 무슨 소용이 있겠습니까?
나는 당신이 의미하는 바를 이해하고 싶지만 작동하지 않습니다. "대기 시간이 지나면 거래 환경을 업데이트하십시오"라는 원칙에 문제가 있다고 보지 않습니다.
주문을 처리하기 전에 수량 및/또는 가격과의 거리를 기준으로 정렬하는 것이 올바른 결정입니다. 그러나 포럼에서 코드를 복사하는 모든 사람이 이를 구현할 것이라고 가정해서는 안 됩니다.
그런 의미에서 내 코드는 더 안전합니다.
글쎄, 그것은 초보자를 위해 작성되지 않았습니다. 우리는 여기에서 물 없이 이것을 아주 잘 논의하고 있습니다.
다시 말하지만 관련성 문제가 있습니다. 하나의 주문은 항상 최신 상태로 유지됩니다. 나머지 - 가능한 경우. 모든 주문이 최신 상태가 아닐 수 있습니다.
최신 - 얼마입니까?
나는 당신이 의미하는 바를 이해하고 싶지만 작동하지 않습니다. "대기 시간이 지나면 거래 환경을 업데이트하십시오"라는 원칙에 문제가 있다고 보지 않습니다.
알고리즘은 목록의 첫 번째 순서에 고정되어 있습니다. 그게 전부입니다.
어떤 상황에서는 이것이 시스템에 해로울 수 있습니다(실제로 이것을 경험했습니다).
최신 - 얼마입니까?
내 버전에서는 두 SL이 모두 1.2375로 수정되거나 최악의 경우 1.2374로 수정됩니다. 결과: 두 주문에 대해 +30 포인트.
귀하의 예에서 모든 단계에서 TS는 거래 주문 없이 주문이 있어야 할 위치를 알아야 합니다. 저것들. 일반적으로 TS는 주문이 현재 있는 위치에 묶일 수 없습니다. 그녀는 그들이 서 있어야 할 위치를 계산하고 거래 주문을 통해 계산한 것과 거래 환경을 동기화하는 데만 관심이 있습니다.
귀하의 예에서 TS의 결과는 OnTick이 높은 가격에 왔는지 여부에 따라 다릅니다. 그리고 올바른 차량은 바로 그 이전에 있어야 합니다. 그녀는 (심지어 OnTick을 건너뛴 경우에도) 그러한 가격이 있음을 확인했으며, 이는 그녀의 SL이 그에 따라 배치되어야 함을 의미합니다. 그리고 동기화는 100% 일을 할 것입니다.
그리고 왜 계속 두 번째 사람이 서 있다고 말하는지 이해가 되지 않습니다. 동기화 논리가 없어도 버전과 동일한 방식으로 수정됩니다. OnTick은 NewTick 이벤트가 아니라 일반적인 내부 함수로 호출됩니다.
귀하의 예에서 모든 단계에서 TS는 거래 주문 없이 주문이 있어야 할 위치를 알아야 합니다. 저것들. 일반적으로 TS는 주문이 현재 있는 위치에 묶일 수 없습니다. 그녀는 그들이 서 있어야 할 위치를 계산하고 거래 주문을 통해 계산한 것과 거래 환경을 동기화하는 데만 관심이 있습니다.
그녀는 알고 있습니다. 그러나 동기화할 시간이 없습니다. 한 번의 수정이 진행되는 동안 가격은 더 올라가고 새로운 계산된 상태는 첫 번째 주문을 다시 수정하라고 알려줍니다. 그래서 항상.
귀하의 예에서 TS의 결과는 OnTick이 높은 가격에 왔는지 여부에 따라 다릅니다. 그리고 올바른 차량은 바로 그 이전에 있어야 합니다. 그녀는 (심지어 OnTick을 건너뛴 경우에도) 그러한 가격이 있음을 확인했으며, 이는 그녀의 SL이 그에 따라 배치되어야 함을 의미합니다. 그리고 동기화는 100% 일을 할 것입니다.
의존하지 않습니다(예제에서는 SL 레벨 계산이 없었습니다).
동기화는 작업을 수행하지 않습니다. 시간이 없습니다(위 참조).
그리고 왜 계속 두 번째 사람이 서 있다고 말하는지 이해가 되지 않습니다. 동기화 논리가 없어도 버전과 동일한 방식으로 수정됩니다. OnTick은 NewTick 이벤트가 아니라 일반적인 내부 함수로 호출됩니다.
평소대로, 나는 그것을 얻었다.
하지만 수정이 진행되는 동안 이미 가격이 변했고, OnTick의 강제 호출은 이미 새 가격으로 작동하고 있는 반면, 2차 주문은 초기 수준을 유지했습니다.
오류가 없습니다. 아마도 당신에게 너무 구체적일 수 있습니다.
그녀는 알고 있습니다. 그러나 동기화할 시간이 없습니다. 한 번의 수정이 진행되는 동안 가격은 더 올라가고 새로운 계산된 상태는 첫 번째 주문을 다시 수정하라고 알려줍니다. 그래서 항상.
귀하가 제공한 예는 부록일 뿐입니다. 그러한 논리에서 손실을 가져오지 않습니다. 이제 저와 함께 예를 들어보겠습니다.
원하는 풀백에서 열리기 위해 이동 뒤에 BuyLimits를 추적한다고 가정해 보겠습니다. 거의 Lucky-TC. 우리가 매번 한계의 산을 끌고 간다면 우리는 당신의 라인에 철수를 잡지 않을 것입니다.
글쎄, 구식 거래 환경을 기반으로 거래 주문 을 발행하는 것은 이상합니다. 하지만 당신은 완고하게 (나처럼) 다른 관점을 옹호합니다.
글쎄요, 구식 거래 환경을 기반으로 거래 주문 을 발행하는 것이 이상합니다. 하지만 당신은 완고하게 (나처럼) 다른 관점을 옹호합니다.
두 가지 악 중에서 작은 것을 선택해야 합니다.
물론 가격에 따라 제한이 있는 예는 "1 Expert Advisor = 각 방향으로 1 주문" 옵션에서 구현하는 것이 좋습니다.
그러나 일반적으로 모든 주문을 통제하는 것이 더 정확합니다.
그러나 일반적으로 모든 주문을 통제하는 것이 더 정확합니다.
저것들. TS가 현재 거래 환경에서만 작동해야 한다는 요구 사항에 동의하지 않습니다.
저것들. TS가 현재 거래 환경에서만 작동해야 한다는 요구 사항에 동의하지 않습니다.
이를 위해 TS의 모든 명령에 대한 제어를 희생해야 한다면 - 물론입니다.
상상해보십시오. 4 대의 트럭이 있습니다. 그들 각각은 A 지점에서 B 지점까지 귀중한 화물을 운반합니다. 경로를 제어해야 합니다.
당신은 무엇을 선호합니까? 매분 - 그들 중 하나와 연결하거나 2분마다 - 그들 모두와 연결하시겠습니까?
두 번째 경우에는 지연 시간이 조금 더 길어지고, 지시할 시간이 없으면 4명 모두 약간 우회해야 할 수도 있습니다. 그러나 일반적으로 트럭 한 대를 가지고 다른 세 대를 잃는 것보다 비즈니스에 더 유리할 것입니다.
이를 위해 TS의 모든 명령에 대한 제어를 희생해야 한다면 - 물론입니다.
상상해보십시오. 4 대의 트럭이 있습니다. 그들 각각은 A 지점에서 B 지점까지 귀중한 화물을 운반합니다. 경로를 제어해야 합니다.
당신은 무엇을 선호합니까? 매분 - 그들 중 하나와 연결하거나 2분마다 - 그들 모두와 연결하시겠습니까?
두 번째 경우에는 지연 시간이 조금 더 길어지고, 지시할 시간이 없으면 4명 모두 약간 우회해야 할 수도 있습니다. 그러나 일반적으로 트럭 한 대를 가지고 다른 세 대를 잃는 것보다 비즈니스에 더 유리할 것입니다.
+1.
아마도 OOP 접근 방식에서는 새로운 아이디어가 나오지 않았을 것입니다. 주문을 반복하는 주기의 아날로그가 OrderModify를 직접 호출하는 대신 수정 명령을 형성하는 관리자와 같은 어떤 종류의 엔터티에 숨겨져 있을 때(모든 매개변수)를 대기열에 넣은 다음 처리합니다. 요점은 위의 코드에서 단일 루프로 채워진 책임을 환경 분석의 특정 개체와 분석을 기반으로 하는 작업을 수행하는 개체로 나누는 것입니다.
아마도 이 아이디어는 OOP 접근 방식에서 발생하지 않았을 것입니다. 주문을 반복하는 주기의 유사체가 OrderModify를 직접 호출하는 대신 수정 명령(모든 매개변수 포함)을 생성하고 관리자와 같은 일부 엔티티에 숨겨져 있을 때 큐에 넣은 다음 처리됩니다. 요점은 위의 코드에서 단일 루프로 채워진 책임을 환경 분석의 특정 개체와 분석을 기반으로 하는 작업을 수행하는 개체로 나누는 것입니다.
비동기식 주문을 통해서만 이러한 상황을 피할 수 있습니다.
그렇지 않으면 실행할 명령 목록을 통해 계속 루프가 있게 되며, 실제로 이것은 명령을 통한 루프입니다.
대기열이 있는 상황에서만 해당 주문과 관련된 이전의 실행되지 않은 주문을 새로운 주문으로 교체하는 것이 여전히 필요합니다. 그렇지 않으면 대기열이 넘칠 수 있고 대기열의 주문이 만료될 수 있습니다.