Andrey Kisselyov : 테스터의 장점을 보자마자 MT5로 바꿨습니다. 그리고 헤지나 그물망은 나에게 거의 관심이 없습니다. 프로그래머 및 테스트 모드 에 따라 다릅니다. 생성 된 진드기에 따르면 완전히 쓰레기입니다. 동의합니다. 실제 진드기의 역사가 도입되면 무언가가 바뀔 것입니다.
내가 기억하는 한 "4"에 OOP가 도입된 것은 부정되지 않았지만 MT5에 고정될 가능성에 대해서는 "계획되지 않음"이라고 말한 적이 있습니다.
이것은 분명히 나중에 개발자는 MT4 주문 시스템이 DC에서 자본을 조직한다는 관점에서 완전히 논리적이지는 않지만 매우, 매우 편리하다는 것을 깨달았습니다.
거래 자체는 시장에서 매수 또는 매도 중 하나의 포지션이 있음을 의미하며, 세 번째는 없습니다. 그리고 이 아이디어가 MT5에서 즉시 구현되었다는 사실은 매우 우수합니다. 다른 방향으로 많은 주문이 있는 모든 슬래그가 거래자로부터 여러 스프레드를 먹고 하나의 항목을 구현하는 것이 더 낫다는 것을 이해하고 결과적으로 , 1 스프레드를 사용하고 동시에 좋은 결과를 얻으십시오. 신호의 수익성을 기반으로하고 다양한 잠금 및 주문의 수학적 트릭을 기반으로하지 않고 이익을 위해 거래하는 모든 시스템을 쉽게 구현하고 만들 수 있습니다. 모든 기기와 플랫폼에서 사용할 수 있습니다.
감사합니다.
추신: OOP의 래퍼는 거래에서 그다지 중요하지 않습니다. 마치 카트의 5번째 바퀴와 같아서 프로그래머는 목발처럼 더 필요합니다.
스프레드는 MT4에서도, 심지어 MT5에서도 시장에 추가로 진입할 때 마다 동일한 스프레드를 먹기 때문에 스프레드와는 관련이 없습니다.
"거래는 하나의 포지션을 갖는다"는 말은 옳았지만, 주문 시스템은 거래자에게 매우 편리한 것으로 판명되었습니다. 개발자가 이 시스템을 MT5에 도입해야 했기 때문에 이러한 조건은 많은 DC에서 설정한 것 같습니다.
아니요, 목발이 아니라 매우 편리한 도구입니다. 프로그래밍의 OOP는 어떤 면에서는 거래의 주문 시스템과 같은 편리함입니다.
퍼짐은 더욱이 매우 큽니다. 포지션을 잠글 수 있을 때 하고 나서 해결 방법을 생각합니다(추가 주문이 열리면서 돈을 벌기 위해 사용했던 볼륨이 증가하여 결과적으로 거래 효율성이 높아집니다. 드랍스), 그리고 그러한 기회가 없을 때 당신은 그것을 닫고 동시에 포지션 자체를 열어야 하는 책임이 커집니다.
누가 무엇을 신경 쓰는지 OOP에 대해 논쟁하지 않겠지만, 특히 최적화 중 테스터에서 성능이 더 중요합니다.
퍼짐은 더욱이 매우 큽니다. 포지션을 잠글 수 있을 때 하고 나서 해결 방법을 생각합니다(추가 주문이 열리면서 돈을 벌기 위해 사용했던 볼륨이 증가하여 결과적으로 거래 효율성이 높아집니다. 드랍스), 그리고 그러한 기회가 없을 때 당신은 그것을 닫고 동시에 포지션 자체를 열어야 하는 책임이 커집니다.
뭐라고요 ? 잠그지 않고 - 다시 열면 모든 것이 똑같은 방식으로 수행됩니다. 잠금 기능이 있는 모든 TS는 잠금 기능이 없는 TS로 변환될 수 있으며, 자산 곡선은 절대적으로 동일하고 예금 부하, 스프레드, 모든 것이 동일합니다.
잠금에는 한 가지 장점이 있습니다. 수동 거래에 시각적으로 편리합니다. "메모"와 같은 것- "여기에 손실 위치가 있습니다. 그러나 TS 자체의 관점에서 볼 때 잠금을 두었다가 열거나 위치를 닫을 지 여부는 전혀 차이가 없습니다. 단, 며칠 동안 잠그면 추가 스왑을 지불해야 합니다(재개봉 시 대비).
테스터의 장점을 보자마자 MT5로 바꿨습니다. 그리고 헤지나 그물망은 나에게 거의 관심이 없습니다.
프로그래머 및 테스트 모드 에 따라 다릅니다. 생성 된 진드기에 따르면 완전히 쓰레기입니다. 동의합니다. 실제 진드기의 역사가 도입되면 무언가가 바뀔 것입니다.
감사합니다.
나는 진드기의 실제 역사에 대해 테스트합니다. 다른 모든 것은 물론 옳지 않습니다.
5-rk에서 구현
그리고 오랫동안, 정확히 몇 개월 이상
버전 600 이전의 구형 MT4에서는 OOP는 말할 것도 없고 최소한 구조가 정말 부족했습니다. 따라서 DLL에서 많은 작업을 수행하고 C#으로 로봇을 작성했습니다.
OOP의 출현으로 삶이 더 재미있어졌습니다. 그리고 일반적으로 상위 5위 안에 헷지가 도입되었을 때 그는 그곳에서 기어 다니기 시작했습니다.
헤헤헤... 그리고 제 추측이 맞았습니다... 머지않아 MT5에 오게 될 거라 믿어 의심치 않았기 때문에 저는 즉시 MT5로 글을 쓰기 시작했습니다.
그리고 헤지 계정의 도입으로 메인 계정은 여전히 MT4 미만이지만 MT5에서만 작업합니다. 그러나 크로스 플랫폼 정의를 사용하면 이제 문제가 없으며 공통 인터페이스를 기반으로 라이브러리를 작성했으며 어떤 플랫폼에서 작업하는지 기억조차 나지 않습니다.
헤헤헤... 그리고 제 추측이 맞았습니다... 머지않아 MT5에 오게 될 거라 믿어 의심치 않았기 때문에 저는 즉시 MT5로 글을 쓰기 시작했습니다.
그리고 헤지 계정의 도입으로 메인 계정은 여전히 MT4 미만이지만 MT5에서만 작업합니다. 그러나 크로스 플랫폼 정의를 사용하면 이제 문제가 없으며 공통 인터페이스를 기반으로 라이브러리를 작성했으며 어떤 플랫폼에서 작업하는지 기억조차 나지 않습니다.
감사합니다.
이것은 MT5의 첫 번째 릴리스가 릴리스되자마자 명백했습니다.
내가 기억하는 한 "4"에 OOP가 도입된 것은 부정되지 않았지만 MT5에 고정될 가능성에 대해서는 "계획되지 않음"이라고 말한 적이 있습니다.
이것은 분명히 나중에 개발자는 MT4 주문 시스템이 DC에서 자본을 조직한다는 관점에서 완전히 논리적이지는 않지만 매우, 매우 편리하다는 것을 깨달았습니다.
내가 기억하는 한 "4"에 OOP가 도입된 것은 부정되지 않았지만 MT5에 고정될 가능성에 대해서는 "계획되지 않음"이라고 말한 적이 있습니다.
이것은 분명히 나중에 개발자는 MT4 주문 시스템이 DC에서 자본을 조직한다는 관점에서 완전히 논리적이지는 않지만 매우, 매우 편리하다는 것을 깨달았습니다.
거래 자체는 시장에서 매수 또는 매도 중 하나의 포지션이 있음을 의미하며, 세 번째는 없습니다. 그리고 이 아이디어가 MT5에서 즉시 구현되었다는 사실은 매우 우수합니다. 다른 방향으로 많은 주문이 있는 모든 슬래그가 거래자로부터 여러 스프레드를 먹고 하나의 항목을 구현하는 것이 더 낫다는 것을 이해하고 결과적으로 , 1 스프레드를 사용하고 동시에 좋은 결과를 얻으십시오. 신호의 수익성을 기반으로하고 다양한 잠금 및 주문의 수학적 트릭을 기반으로하지 않고 이익을 위해 거래하는 모든 시스템을 쉽게 구현하고 만들 수 있습니다. 모든 기기와 플랫폼에서 사용할 수 있습니다.
감사합니다.
추신: OOP의 래퍼는 거래에서 그다지 중요하지 않습니다. 마치 카트의 5번째 바퀴와 같아서 프로그래머는 목발처럼 더 필요합니다.
거래 자체는 시장에서 매수 또는 매도 중 하나의 포지션이 있음을 의미하며, 세 번째는 없습니다. 그리고 이 아이디어가 MT5에서 즉시 구현되었다는 사실은 매우 우수합니다. 다른 방향으로 많은 주문이 있는 모든 슬래그가 트레이더의 여러 스프레드를 먹었기 때문입니다.
스프레드는 MT4에서도, 심지어 MT5에서도 시장에 추가로 진입할 때 마다 동일한 스프레드를 먹기 때문에 스프레드와는 관련이 없습니다.
"거래는 하나의 포지션을 갖는다"는 말은 옳았지만, 주문 시스템은 거래자에게 매우 편리한 것으로 판명되었습니다. 개발자가 이 시스템을 MT5에 도입해야 했기 때문에 이러한 조건은 많은 DC에서 설정한 것 같습니다.
추신: OOP의 래퍼는 거래에서 그다지 중요하지 않습니다. 마치 카트의 5번째 바퀴와 같아서 프로그래머는 목발처럼 더 필요합니다.
아니요, 목발이 아니라 매우 편리한 도구입니다. 프로그래밍의 OOP는 어떤 면에서는 거래의 주문 시스템과 같은 편리함입니다.
그렇다면 포럼은 무엇을 위한 것입니까? 이게 다 환상이라면?
손가락에 있다면: 로봇을 쓰다
뻔하다
테스터에서 로봇을 떼어 현실 세계에 길들이는 일만 남았습니다.
스프레드는 MT4에서도, 심지어 MT5에서도 시장에 추가로 진입할 때 마다 동일한 스프레드를 먹기 때문에 스프레드와는 관련이 없습니다.
"거래는 하나의 포지션을 갖는다"는 말은 옳았지만, 주문 시스템은 거래자에게 매우 편리한 것으로 판명되었습니다. 개발자가 이 시스템을 MT5에 도입해야 했기 때문에 이러한 조건은 많은 DC에서 설정한 것 같습니다.
아니요, 목발이 아니라 매우 편리한 도구입니다. 프로그래밍의 OOP는 어떤 면에서는 거래의 주문 시스템과 같은 편리함입니다.
퍼짐은 더욱이 매우 큽니다. 포지션을 잠글 수 있을 때 하고 나서 해결 방법을 생각합니다(추가 주문이 열리면서 돈을 벌기 위해 사용했던 볼륨이 증가하여 결과적으로 거래 효율성이 높아집니다. 드랍스), 그리고 그러한 기회가 없을 때 당신은 그것을 닫고 동시에 포지션 자체를 열어야 하는 책임이 커집니다.
누가 무엇을 신경 쓰는지 OOP에 대해 논쟁하지 않겠지만, 특히 최적화 중 테스터에서 성능이 더 중요합니다.
감사합니다.
퍼짐은 더욱이 매우 큽니다. 포지션을 잠글 수 있을 때 하고 나서 해결 방법을 생각합니다(추가 주문이 열리면서 돈을 벌기 위해 사용했던 볼륨이 증가하여 결과적으로 거래 효율성이 높아집니다. 드랍스), 그리고 그러한 기회가 없을 때 당신은 그것을 닫고 동시에 포지션 자체를 열어야 하는 책임이 커집니다.
뭐라고요 ? 잠그지 않고 - 다시 열면 모든 것이 똑같은 방식으로 수행됩니다. 잠금 기능이 있는 모든 TS는 잠금 기능이 없는 TS로 변환될 수 있으며, 자산 곡선은 절대적으로 동일하고 예금 부하, 스프레드, 모든 것이 동일합니다.
잠금에는 한 가지 장점이 있습니다. 수동 거래에 시각적으로 편리합니다. "메모"와 같은 것- "여기에 손실 위치가 있습니다. 그러나 TS 자체의 관점에서 볼 때 잠금을 두었다가 열거나 위치를 닫을 지 여부는 전혀 차이가 없습니다. 단, 며칠 동안 잠그면 추가 스왑을 지불해야 합니다(재개봉 시 대비).