이 응용 프로그램에 답이 없습니다. 그것의 마지막 코멘트는 2011.06.21 09:25의 제 것입니다(문제의 관련성을 반복적으로 상기시켜줍니다).
다음의 경우에 대비하여 여기에 복제하십시오.
거래/주문의 최소 수량/로트에 대한 제한 은 포지션을 여는 경우에만 관련이 있다는 것을 정확히 이해하고 있습니까? 이 요구 사항 은 포지션을 마감, 증가, 감소 또는 취소하는거래/주문 에 적용 되지 않습니까? 최소 거래 단계에 대한 제한은 위의 5가지 시나리오 모두에 적용됩니다. 가능한 모든 시나리오가 설명된 것 같습니다. 아니면 이 5(5) 외에 다른 것이 있습니까?
당신은 두 번 대답했고 나는 대답했습니다. 다시 대답하겠습니다. 예, 수량 제한 규칙은 완전한 폐쇄에 적용되지 않습니다.
레나트 , 오해하지 마세요. 나는 애지중지하기 위해서가 아니라 명확히하기 위해 내 질문을 반복합니다. 지금까지 귀하의 답변과 동료(SD)는 2(2) 시나리오: 1) 포지션 개설 , 2) 포지션 완전 청산(아마도 ORDER_FILLING_AON 필수 사용)에 대해 우려하고 있습니다. 주문(트랜잭션) 실행의 결과 는 증가 , 감소 또는 포지션 반전 과 같은 최소 3가지 시나리오가 될 수 있습니다 . 불행히도 MQ의 답변에서 이 세 가지 시나리오에 대한 명확한 설명을 찾지 못했습니다. :(
명확성을 위해 몇 가지 예를 제시하겠습니다(서버의 모든 경우 에 최소 로트 = 1.0 , 최소 단계 = 0.1).
예 1(위치 축소). 거래량이 1.0인 롱 포지션이 있습니다. ( ORDER_FILLING_CANCEL 사용) 포지션을 완전히 청산하려고 합니다. 1.0랏 수량의 매도 주문을 보내드립니다. 주문이 부분적으로 실행됩니다(0.9랏). 이 상품의 결과는 0.1랏의 클로즈드 롱 포지션입니다. 따라서 우리는 포지션 축소 시나리오의 경우 최소 로트 크기에 대한 요구 사항 이 적용되지 않는다는 결론을 내립니다.
예 2(위치 반전). 0.1랏의 롱포지션이 있습니다. 0.2랏 수량의 매도 주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까? (최소 로트에 대한 요구 사항이 다시 충족되지 않음).
예 3(포지션 구축). 0.1랏의 롱포지션이 있습니다. 0.1랏 수량의 매수주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까?
명확성을 위해 몇 가지 예를 제시하겠습니다(서버의 모든 경우 에 최소 로트 = 1.0 , 최소 단계 = 0.1).
예 1(위치 축소). 거래량이 1.0인 롱 포지션이 있습니다. ( ORDER_FILLING_CANCEL 사용) 포지션을 완전히 청산하려고 합니다. 1.0랏 수량의 매도 주문을 보내드립니다. 주문이 부분적으로 실행됩니다(0.9랏). 이 상품의 결과는 0.1랏의 클로즈드 롱 포지션입니다. 따라서 우리는 포지션 축소 시나리오의 경우 최소 로트 크기에 대한 요구 사항 이 적용되지 않는다는 결론을 내립니다.
위치가 0.9에서 부분적으로 마감된 경우(그리고 주문이 1.0에서) 0.1에서 잔액을 다시 마감하기 위해 주문을 보내야 합니다.
게다가 실행이 외부 게이트웨이에서 발생하면 1.0에서 전체 볼륨을 한 번에 닫을 수만 있고 분할을 허용하지 않을 가능성이 높습니다.
예 2(위치 반전).
0.1랏의 롱포지션이 있습니다. 0.2랏 수량의 매도 주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까? (최소 로트에 대한 요구 사항이 다시 충족되지 않음).
이는 포지션을 0으로 완전히 청산하는 작업이 아니므로 주문이 거부됩니다.
예 3(포지션 구축). 0.1랏의 롱포지션이 있습니다. 0.1랏 수량의 매수주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까?
당연히 아니지.
규칙을 문자 그대로 읽고 자신의 조건을 생각해내지 마십시오. 규칙은 간단합니다. "ZERO에서 포즈를 청산할 때 볼륨 제한 규칙이 적용되지 않을 수 있습니다." 이 규칙은 반복적으로 표명되었습니다.
또한 모든 브로커 또는 교환 게이트웨이가 자체적이고 보다 엄격한 볼륨 제어 규칙을 사용할 수 있다는 점을 고려해야 합니다.
Renat , 가능하면 SD의 애플리케이션 #124661에 주의하십시오.
6월 13일부터 답변을 기다리고 있습니다.
Renat , 가능하면 SD의 애플리케이션 #124661에 주의하십시오.
6월 13일부터 답변을 기다리고 있습니다.
그래서 당신은 반복해서 정답을 주었습니다. 다시 답변해 주셨습니다.
그래서 당신은 반복해서 정답을 주었습니다. 다시 답변해 주셨습니다.
이 응용 프로그램에 답이 없습니다. 그것의 마지막 코멘트는 2011.06.21 09:25의 제 것입니다(문제의 관련성을 반복적으로 상기시켜줍니다).
다음의 경우에 대비하여 여기에 복제하십시오.
거래/주문의 최소 수량/로트에 대한 제한 은 포지션을 여는 경우에만 관련이 있다는 것을 정확히 이해하고 있습니까?
이 요구 사항 은 포지션을 마감, 증가, 감소 또는 취소하는 거래/주문 에 적용 되지 않습니까?
최소 거래 단계에 대한 제한은 위의 5가지 시나리오 모두에 적용됩니다.
가능한 모든 시나리오가 설명된 것 같습니다. 아니면 이 5(5) 외에 다른 것이 있습니까?
당신은 두 번 대답했고 나는 대답했습니다.
다시 대답하겠습니다. 예, 수량 제한 규칙은 완전한 폐쇄에 적용되지 않습니다.
MQL5의 속도를 높이는 것을 말씀하시는 건가요?
당신은 두 번 대답했고 나는 대답했습니다.
다시 대답하겠습니다. 예, 수량 제한 규칙은 완전한 폐쇄에 적용되지 않습니다.
레나트 , 오해하지 마세요. 나는 애지중지하기 위해서가 아니라 명확히하기 위해 내 질문을 반복합니다.
지금까지 귀하의 답변과 동료(SD)는 2(2) 시나리오: 1) 포지션 개설 , 2) 포지션 완전 청산(아마도 ORDER_FILLING_AON 필수 사용)에 대해 우려하고 있습니다.
주문(트랜잭션) 실행의 결과 는 증가 , 감소 또는 포지션 반전 과 같은 최소 3가지 시나리오가 될 수 있습니다 .
불행히도 MQ의 답변에서 이 세 가지 시나리오에 대한 명확한 설명을 찾지 못했습니다. :(
명확성을 위해 몇 가지 예를 제시하겠습니다(서버의 모든 경우 에 최소 로트 = 1.0 , 최소 단계 = 0.1).
예 1 (위치 축소).
거래량이 1.0인 롱 포지션이 있습니다. ( ORDER_FILLING_CANCEL 사용) 포지션을 완전히 청산하려고 합니다. 1.0랏 수량의 매도 주문을 보내드립니다. 주문이 부분적으로 실행됩니다(0.9랏).
이 상품의 결과는 0.1랏의 클로즈드 롱 포지션입니다. 따라서 우리는 포지션 축소 시나리오의 경우 최소 로트 크기에 대한 요구 사항 이 적용되지 않는다는 결론을 내립니다.
예 2(위치 반전).
0.1랏의 롱포지션이 있습니다. 0.2랏 수량의 매도 주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까? (최소 로트에 대한 요구 사항이 다시 충족되지 않음).
예 3(포지션 구축).
0.1랏의 롱포지션이 있습니다. 0.1랏 수량의 매수주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까?
명확성을 위해 몇 가지 예를 제시하겠습니다(서버의 모든 경우 에 최소 로트 = 1.0 , 최소 단계 = 0.1).
예 1 (위치 축소).
거래량이 1.0인 롱 포지션이 있습니다. ( ORDER_FILLING_CANCEL 사용) 포지션을 완전히 청산하려고 합니다. 1.0랏 수량의 매도 주문을 보내드립니다. 주문이 부분적으로 실행됩니다(0.9랏).
이 상품의 결과는 0.1랏의 클로즈드 롱 포지션입니다. 따라서 우리는 포지션 축소 시나리오의 경우 최소 로트 크기에 대한 요구 사항 이 적용되지 않는다는 결론을 내립니다.
위치가 0.9에서 부분적으로 마감된 경우(그리고 주문이 1.0에서) 0.1에서 잔액을 다시 마감하기 위해 주문을 보내야 합니다.
게다가 실행이 외부 게이트웨이에서 발생하면 1.0에서 전체 볼륨을 한 번에 닫을 수만 있고 분할을 허용하지 않을 가능성이 높습니다.
예 2(위치 반전).
0.1랏의 롱포지션이 있습니다. 0.2랏 수량의 매도 주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까? (최소 로트에 대한 요구 사항이 다시 충족되지 않음).
예 3(포지션 구축).
0.1랏의 롱포지션이 있습니다. 0.1랏 수량의 매수주문을 서버로 보냅니다. 서버가 그러한 주문의 예입니까?
당연히 아니지.
규칙을 문자 그대로 읽고 자신의 조건을 생각해내지 마십시오. 규칙은 간단합니다. "ZERO에서 포즈를 청산할 때 볼륨 제한 규칙이 적용되지 않을 수 있습니다." 이 규칙은 반복적으로 표명되었습니다.
또한 모든 브로커 또는 교환 게이트웨이가 자체적이고 보다 엄격한 볼륨 제어 규칙을 사용할 수 있다는 점을 고려해야 합니다.
여는/닫는 대괄호 강조 표시가 작동하는 최대 줄 수는 128개입니다. 이 제한은 한 화면에 맞지 않는 여는 대괄호와 닫는 대괄호를 강조 표시하는 것이 의미가 없기 때문에 도입되었습니다. 또한 이 제한 사항이 도입된 후 MetaEditor의 성능이 크게 향상되었습니다.
근본적인 질문은 아니지만 여전히. 문자열 연결. 설명서에는 StringAdd 및 StringConcatenate의 두 가지 기능 이 설명되어 있습니다.
...
결과:
2011.06.26 19:10:55 테스트 (EURUSD,H1) №1 2012 밀리초, i = 10000000
2011.06.26 19:11:04 테스트(EURUSD,H1) №2 8269 밀리초, i = 10000000
2011.06.26 19:11:10 테스트(EURUSD,H1) №3 6661 밀리초, i = 10000000
그러나 일반 덧셈이 더 빠릅니다 .
예가 잘못되었습니다.
첫 번째 방법에는 "결과 = 결과 + 문자열1 + 문자열2 + 문자열3;"이 있어야 합니다.
그리고 나는 세 가지 테스트 모두에 대해 다른 결과를 만들었을 것입니다. 그렇지 않으면 불평등한 조건에서 시작합니다(일부 메모리가 이미 할당됨).
더 나은 방법은 테스트를 다른 스크립트로 분리하여 순차적으로 실행하는 것입니다.
나는 다음과 같이 얻었다.
1. 길이 = 10`000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) №2 0 밀리초, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #3 0 밀리초, i = 10000
2. 길이 = 100`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 15 밀리초, i = 1000000
엔딩 #1 - 기다리지 않았다
3. 길이 = 1`000`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 187 밀리초, i = 1000000
엔딩 #1 - 기다리지 않았다
4. 길이 = 10`000`000
2차 테스트에서 "MemoryException: 602492946 bytes not available" 오류가 로그에 나타나기 시작하여 스크립트가 수동으로 삭제되었습니다.
결론: StringConcatenate가 가장 빠릅니다.
그런데 StringAdd 함수에 대한 참조에서도 아주 정확한 비교 예가 없습니다.
내 인증 코드는 예고편에 있습니다.