Nikolai, 귀하의 게시물은 매우 제정신이지만 제안된 계획(보편성)을 옹호할 것을 약속합니다.
빨간색으로 표시된 모든 것이 매우 안정적이고 플랫폼에서 제공되는 모든 것이 수년 동안 변경되지 않았습니다. 다른 플랫폼에 필요한 경우 확립된 API도 있으므로 다시 작성하는 것은 문제가 되지 않습니다.
동의한다. Vasily를 위해 (이 기회에) 설명하고 싶습니다. 계획에 반영된 중요한 아이디어 중 하나는 플랫폼 종속 부품의 수가 아니라 엄격한 현지화입니다. 즉: TS 자체(예측자 + MM 모듈)는 플랫폼 독립적인 설계이며 데이터 소스는 각각 지표 및 시장 동인입니다(추천 수정자의 입력에 제공된 거래 내역도 본질적으로 지표입니다. ).
그 결과 명확하게 구분할 수 있고 다음과 같은 경우 교차하지 않는 명확하게 정의된 간섭 영역이 생성됩니다.
1. 마이그레이션.
2. 차량의 개선. 특히 스케일링.
그러나 녹색 화살표가 있는 모든 모듈은 자체 모듈이며 거의 항상 활성 재작업입니다(이상에는 제한이 없습니다).
물론이죠. 그러나 수정 사항에 대해 플랫폼 종속/독립 시스템 구성 요소로의 분할을 주의 깊게 준수한다면 예를 들어 현재 현실에서 두 플랫폼(MT4/5)에 대한 Expert Advisor의 개발을 쉽게 지원할 수 있습니다. 플랫폼 종속 TS를 사용하면 상당한 출혈이 발생했을 것입니다.
방향 예측가가 썼던대로, 새로운 아이디어가 깊어지고 확장되었습니다. 글쎄, 지금은 일반적으로 매수이지만 매도를 준비해야하며 점차 볼륨을 축소해야합니다.
그리고 이미 두 개의 모듈을 조이겠습니다.
다이어그램에서 강조 표시된 구성 요소 내부에는 원하는 수의 모듈이 있을 수 있습니다. 이건 괜찮아. 나는 그들의 명확한 컨베이어 배열만이 유용하다고 생각합니다. 절대적으로 불가피한 경우 없이 코드 내부에서 혼동되어서는 안 됩니다. 저것들. 혼합은 가능한 한 피해야 합니다. 이를 통해 다중 기기 방향으로 확장할 때 모듈에 대해 항상 잘 정의되고 편리한 도킹 지점을 가질 수 있습니다. 이 각도에서 다이어그램을 보면 스스로 찾을 수 있습니다.
MM 교정기도 역동적인 방식으로, 이제는 포즈와 함께 작동하다가 갑자기 추워져서 보충(시장에 원활하게 진입)을 위해 리메이크하기로 결정했습니다.
위 참조. // 반면에 MM 교정기의 입력은 단일 통화(단일 기기, 보다 정확하게는) 예보자의 클라우드를 다중 통화(다중 기기) 주방으로 통합하는 데 가장 편리한 지점입니다.
Market Driver에서는 플랫폼 종속적인 API에 액세스할 수 있기 때문에 안정적인 것 같으므로 형식화가 명확하지만 거기서 망칠 것입니다. API가 많은 기회를 제공하기 때문에 걱정하지 마십시오.
아무도 어려움이 전혀 없다고 약속하지 않았습니다. :) 그러나 이러한 모든 직접 API 호출이 아직 드라이버에서 현지화되지 않았지만 예측기 및 MM 모듈의 코드와 혼합되어 있는지 생각해보십시오.............
MetaDriver : Nikolai, 귀하의 게시물은 매우 제정신이지만 제안된 계획(보편성)을 옹호할 것을 약속합니다.
동의한다. Vasily를 위해 (이 기회에) 설명하고 싶습니다. 계획에 반영된 중요한 아이디어 중 하나는 플랫폼 종속 부품의 수가 아니라 엄격한 현지화입니다. 즉: TS 자체(예측자 + MM 모듈)는 플랫폼 독립적인 설계이며 데이터 소스는 각각 지표 및 시장 동인입니다(추천 수정자의 입력에 제공된 거래 내역도 본질적으로 지표입니다. ).
그 결과 명확하게 구분할 수 있고 다음과 같은 경우 교차하지 않는 명확하게 정의된 간섭 영역이 생성됩니다.
1. 마이그레이션.
2. 차량의 개선. 특히 스케일링.
물론이죠. 그러나 수정 사항에 대해 플랫폼 종속/독립 시스템 구성 요소로의 분할을 주의 깊게 준수한다면 예를 들어 현재 현실에서 두 플랫폼(MT4/5)에 대한 Expert Advisor의 개발을 쉽게 지원할 수 있습니다. 플랫폼 종속 TS를 사용하면 상당한 출혈이 발생했을 것입니다.
다이어그램에서 강조 표시된 구성 요소 내부에는 원하는 수의 모듈이 있을 수 있습니다. 이건 괜찮아. 나는 그들의 명확한 컨베이어 배열만이 유용하다고 생각합니다. 절대적으로 불가피한 경우 없이 코드 내부에서 혼동되어서는 안 됩니다. 저것들. 혼합은 가능한 한 피해야 합니다. 이를 통해 다중 기기 방향으로 확장할 때 모듈에 대해 항상 잘 정의되고 편리한 도킹 지점을 가질 수 있습니다. 이 각도에서 다이어그램을 보면 스스로 찾을 수 있습니다.
위 참조. // 반면에 MM 교정기의 입력은 단일 통화(단일 기기, 보다 정확하게는) 예보자의 클라우드를 다중 통화(다중 기기) 주방으로 통합하는 데 가장 편리한 지점입니다.
아무도 어려움이 전혀 없다고 약속하지 않았습니다. :) 그러나 이러한 모든 직접 API 호출이 아직 드라이버에서 현지화되지 않았지만 예측기 및 MM 모듈의 코드와 혼합되어 있는지 생각해보십시오.............
;)
좋아, 이것을 기초로 합시다. (그냥 정지 작업을 위한 모듈을 추가하면 합리적이고 아무도 이의를 제기하지 않습니다),
좋아, 이것을 기초로 합시다. (그냥 정지 작업을 위한 모듈을 추가하면 합리적이고 아무도 이의를 제기하지 않습니다),
이 계획에서 여전히 누락된 것이 무엇인지 생각하거나 다시 실행하십시오.
변경 개선을 희생하면서 (끓게 두십시오) 생각합니다.
결핍은 더 분명합니다. 이 체계에는 GUI(시각적 모니터링/제어 하위 시스템)가 분명히 부족합니다. EA와 GUI 간의 통합된 (편리한!) 상호 작용 방식을 개발하고 싶습니다. 지금까지 나는 이 문제에 대해 자발성을 가지고 있는데, 이는 정말로 나를 짜증나게 한다. 동일한 목표(양방향으로 완전한 데이터 추상화)를 달성하고 싶습니다. 이 문제는 아직 해결되지 않았습니다. 그래서 교육을 위해 어드바이저/GUI를 도킹하는 작업을 제안한 것입니다. 상업적인 관심이 있고 대중의 아이디어를 수집하고 싶었습니다.
MetaDriver : 다이어그램에서 강조 표시된 구성 요소 내부에는 원하는 수의 모듈이 있을 수 있습니다. 이건 괜찮아. 나는 그들의 명확한 컨베이어 배열만이 유용하다고 생각합니다. 절대적으로 불가피한 경우 없이 코드 내부에서 혼동되어서는 안 됩니다. 저것들. 혼합은 가능한 한 피해야 합니다. 이를 통해 다중 기기 방향으로 확장할 때 모듈에 대해 항상 잘 정의되고 편리한 도킹 지점을 가질 수 있습니다. 이 각도에서 다이어그램을 보면 스스로 찾을 수 있습니다.
무한한 모듈 성장은 미래에 심각한 문제로 이어집니다. Expert Advisor의 논리는 실제로 다른 모듈에 분산되어 있습니다. 모듈 자체는 서로 상호 작용하며 모듈 간의 연결이 얽힌 엉킴으로 바뀌지 않는다는 보장은 없습니다. IMHO, 녹색으로 표시된 모든 사각형은 하나의 거래 시스템의 요소입니다. 그것들이 다른 모듈로 분해될 때, 프로그래밍의 주요 원칙 중 하나인 단일 작업 내에서 데이터와 메소드의 캡슐화를 위반합니다.
모두가 회로도를 게시하기 시작했기 때문에 나도 계속할 것입니다. 이번에는 더욱 추상적인 계획:
검은색 화살표는 엄격한 관계를 나타냅니다. 회색 - 모듈 내 사적인 관계, 중요하지 않습니다. 또한 거래 로봇 클래스는 플랫폼 API에 직접 접근할 수 있는 권한을 가지지만 이는 플랫폼 독립성을 감소시킨다.
무한한 모듈 성장은 미래에 심각한 문제로 이어집니다. Expert Advisor의 논리는 실제로 다른 모듈에 분산되어 있습니다. 모듈 자체는 서로 상호 작용하며 모듈 간의 연결이 얽힌 엉킴으로 바뀌지 않는다는 보장은 없습니다. IMHO, 녹색으로 표시된 모든 사각형은 하나의 거래 시스템의 요소입니다. 그것들이 다른 모듈로 분해될 때, 프로그래밍의 주요 원칙 중 하나인 단일 작업 내에서 데이터와 메소드의 캡슐화를 위반합니다.
모두가 회로도를 게시하기 시작했기 때문에 나도 계속할 것입니다. 이번에는 더 추상적인 계획:
검은색 화살표는 엄격한 관계를 나타냅니다. 회색 - 모듈 내 사적인 관계, 중요하지 않습니다. 또한 거래 로봇 클래스는 플랫폼 API에 직접 접근할 수 있는 권한을 가지지만 이는 플랫폼 독립성을 감소시킨다.
그리고 call 모듈을 통해 API를 호출한다면? 그런 다음 하나의 모듈을 변경하여 플랫폼을 변경할 수 있습니다.
결핍은 더 분명합니다. 이 체계에는 GUI(시각적 모니터링/제어 하위 시스템)가 분명히 부족합니다. EA와 GUI 간의 통합된 (편리한!) 상호 작용 방식을 개발하고 싶습니다. 지금까지 나는 이 문제에 대해 자발성을 가지고 있는데, 이는 정말로 나를 짜증나게 한다. 동일한 목표(양방향으로 완전한 데이터 추상화)를 달성하고 싶습니다. 이 문제는 아직 해결되지 않았습니다. 그래서 교육을 위해 어드바이저/GUI를 도킹하는 작업을 제안한 것입니다. 상업적인 관심이 있고 대중의 아이디어를 수집하고 싶었습니다.
작업에서 벗어나십시오. GUI에서 가장 수요가 많은 작업은 무엇입니까? 당신은 개인적으로.
거기에서 춤을. 얻고자 하는 것을 설명하고, 일반적인 단점을 강조 표시하고, 스켈레톤을 만든 다음, 다른 것을 추가하고, 스켈레톤을 변경하는 것이 얼마나 쉬운지 확인하십시오.
MetaDriver 는 모든 것을 올바르게 말하고 그의 시스템은 정확합니다. Fuck_fx는 또한 "거래 드라이버"가 최고의 가격을 사용하기 위해 10-20개 플랫폼에서 작동해야 한다고 덧붙였습니다.
그러나 전략에 오류가없고, 사용자 개입이없고, 불가항력이없는 이상적인 조건에서만 이러한 올바른 시스템을 사용하는 것이 편리합니다. 그러나 실제로는 거의 발생하지 않습니다.
나는 Horseradish_fx의 예를 확장할 것입니다: 25개의 전략이 작동하고, 애그리게이터(거래 동인)가 그것들을 순 위치에서 수집하고 시장에 가져옵니다. 모든 것이 정상입니다. 갑자기 17번째 전략에서 무언가가 중단되고 건강에 좋지 않은 예측이 나옵니다. 창고의 50%에서 열린다고 합니다. 고문은 순순히 열립니다.
MT4의 평범한 사물함의 기능은 다음과 같습니다.
차트에서 17번째 고문을 제거합니다(거래의 마법으로 쉽게 찾을 수 있음).
해당 위치(MT4 기준) 또는 위치의 일부(MT5 기준)를 닫습니다.
이 EA가 생성한 로그를 읽어 상황을 분석합니다.
이제 "정확한 회계"로 넘어 갑시다. 오류를 제거하기 위해 거래자는 무엇을 해야 합니까(50% 마진 거래는 논리상의 명백한 오류입니다):
어떤 전략이 그것을 생성했는지 (어떻게? 로그에서?),
관련 코드를 찾아 변경합니다(return(0)?),
또는 위치 합계 주기에서 원하는 전략과 반대 방향으로(숫자를 잘못 입력하면 안 됩니다!) put 계속;
Expert Advisor를 컴파일합니다(MT4인 경우 - 터미널을 닫거나 컴파일 후 올바른 설정을 지정한 후).
오, 블라디미르, 당신의 계획으로 모든 것이 그렇게 간단하지는 않습니다. 드라이버만 다시 작성해야 한다고 말씀하십니까? 그러나 훨씬 더 많은 플랫폼 종속 부분을 계산했습니다.
시장 내역과 거래 내역을 어떻게 얻을 수 있습니까? 그리고 당신은 실수로 터미널에서가 아닌 현재 위치에 대한 정보를 가져갈 것입니까? 그리고 변동성 모듈을 구현해야 하는 경우 - 또 다른 플랫폼 종속 API?
어댑터를 작성하시겠습니까? 그리고 몇 개나 될까요? 시장 기록용 - 하나의 어댑터, 거래 기록용 - 다른 어댑터, 포지션 작업용 - 세 번째 결과적으로 두 배 많은 모듈과 동일한 수의 플랫폼 종속 코드가 있습니다.
나는 다른 곳에서 문제를 본다.
빨간색으로 표시된 모든 것이 매우 안정적이고 플랫폼에서 제공되는 모든 것이 수년 동안 변경되지 않았습니다. 다른 플랫폼에 필요한 경우 확립된 API도 있으므로 다시 작성하는 것은 문제가 되지 않습니다.
그러나 녹색 화살표가 있는 모든 모듈은 자체 모듈이며 거의 항상 활성 재작업입니다(이상에는 제한이 없습니다).
방향 예측가가 썼던대로, 새로운 아이디어가 깊어지고 확장되었습니다. 글쎄, 지금은 일반적으로 매수이지만 매도를 준비해야하며 점차 볼륨을 축소해야합니다.
그리고 이미 두 개의 모듈을 조이겠습니다.
MM 교정기도 역동적인 방식으로, 이제는 포즈와 함께 작동하다가 갑자기 추워져서 보충(시장에 원활하게 진입)을 위해 리메이크하기로 결정했습니다.
Market Driver에서는 플랫폼 종속적인 API에 액세스할 수 있기 때문에 안정적인 것 같으므로 형식화가 명확하지만 거기서 망칠 것입니다. API가 많은 기회를 제공하기 때문에 걱정하지 마십시오.
나는 다른 곳에서 문제를 본다.
빨간색으로 표시된 모든 것이 매우 안정적이고 플랫폼에서 제공되는 모든 것이 수년 동안 변경되지 않았습니다. 다른 플랫폼에 필요한 경우 확립된 API도 있으므로 다시 작성하는 것은 문제가 되지 않습니다.
동의한다. Vasily를 위해 (이 기회에) 설명하고 싶습니다. 계획에 반영된 중요한 아이디어 중 하나는 플랫폼 종속 부품의 수가 아니라 엄격한 현지화입니다. 즉: TS 자체(예측자 + MM 모듈)는 플랫폼 독립적인 설계이며 데이터 소스는 각각 지표 및 시장 동인입니다(추천 수정자의 입력에 제공된 거래 내역도 본질적으로 지표입니다. ).
그 결과 명확하게 구분할 수 있고 다음과 같은 경우 교차하지 않는 명확하게 정의된 간섭 영역이 생성됩니다.
1. 마이그레이션.
2. 차량의 개선. 특히 스케일링.
그러나 녹색 화살표가 있는 모든 모듈은 자체 모듈이며 거의 항상 활성 재작업입니다(이상에는 제한이 없습니다).
방향 예측가가 썼던대로, 새로운 아이디어가 깊어지고 확장되었습니다. 글쎄, 지금은 일반적으로 매수이지만 매도를 준비해야하며 점차 볼륨을 축소해야합니다.
그리고 이미 두 개의 모듈을 조이겠습니다.
MM 교정기도 역동적인 방식으로, 이제는 포즈와 함께 작동하다가 갑자기 추워져서 보충(시장에 원활하게 진입)을 위해 리메이크하기로 결정했습니다.
Market Driver에서는 플랫폼 종속적인 API에 액세스할 수 있기 때문에 안정적인 것 같으므로 형식화가 명확하지만 거기서 망칠 것입니다. API가 많은 기회를 제공하기 때문에 걱정하지 마십시오.
아무도 어려움이 전혀 없다고 약속하지 않았습니다. :) 그러나 이러한 모든 직접 API 호출이 아직 드라이버에서 현지화되지 않았지만 예측기 및 MM 모듈의 코드와 혼합되어 있는지 생각해보십시오.............
;)
Nikolai, 귀하의 게시물은 매우 제정신이지만 제안된 계획(보편성)을 옹호할 것을 약속합니다.
동의한다. Vasily를 위해 (이 기회에) 설명하고 싶습니다. 계획에 반영된 중요한 아이디어 중 하나는 플랫폼 종속 부품의 수가 아니라 엄격한 현지화입니다. 즉: TS 자체(예측자 + MM 모듈)는 플랫폼 독립적인 설계이며 데이터 소스는 각각 지표 및 시장 동인입니다(추천 수정자의 입력에 제공된 거래 내역도 본질적으로 지표입니다. ).
그 결과 명확하게 구분할 수 있고 다음과 같은 경우 교차하지 않는 명확하게 정의된 간섭 영역이 생성됩니다.
1. 마이그레이션.
2. 차량의 개선. 특히 스케일링.
물론이죠. 그러나 수정 사항에 대해 플랫폼 종속/독립 시스템 구성 요소로의 분할을 주의 깊게 준수한다면 예를 들어 현재 현실에서 두 플랫폼(MT4/5)에 대한 Expert Advisor의 개발을 쉽게 지원할 수 있습니다. 플랫폼 종속 TS를 사용하면 상당한 출혈이 발생했을 것입니다.다이어그램에서 강조 표시된 구성 요소 내부에는 원하는 수의 모듈이 있을 수 있습니다. 이건 괜찮아. 나는 그들의 명확한 컨베이어 배열만이 유용하다고 생각합니다. 절대적으로 불가피한 경우 없이 코드 내부에서 혼동되어서는 안 됩니다. 저것들. 혼합은 가능한 한 피해야 합니다. 이를 통해 다중 기기 방향으로 확장할 때 모듈에 대해 항상 잘 정의되고 편리한 도킹 지점을 가질 수 있습니다. 이 각도에서 다이어그램을 보면 스스로 찾을 수 있습니다.
위 참조. // 반면에 MM 교정기의 입력은 단일 통화(단일 기기, 보다 정확하게는) 예보자의 클라우드를 다중 통화(다중 기기) 주방으로 통합하는 데 가장 편리한 지점입니다.아무도 어려움이 전혀 없다고 약속하지 않았습니다. :) 그러나 이러한 모든 직접 API 호출이 아직 드라이버에서 현지화되지 않았지만 예측기 및 MM 모듈의 코드와 혼합되어 있는지 생각해보십시오.............
;)
좋아, 이것을 기초로 합시다. (그냥 정지 작업을 위한 모듈을 추가하면 합리적이고 아무도 이의를 제기하지 않습니다),
이 계획에서 여전히 누락된 것이 무엇인지 생각하거나 다시 실행하십시오.
좋아, 이것을 기초로 합시다. (그냥 정지 작업을 위한 모듈을 추가하면 합리적이고 아무도 이의를 제기하지 않습니다),
이 계획에서 여전히 누락된 것이 무엇인지 생각하거나 다시 실행하십시오.
변경 개선을 희생하면서 (끓게 두십시오) 생각합니다.
결핍은 더 분명합니다. 이 체계에는 GUI(시각적 모니터링/제어 하위 시스템)가 분명히 부족합니다. EA와 GUI 간의 통합된 (편리한!) 상호 작용 방식을 개발하고 싶습니다. 지금까지 나는 이 문제에 대해 자발성을 가지고 있는데, 이는 정말로 나를 짜증나게 한다. 동일한 목표(양방향으로 완전한 데이터 추상화)를 달성하고 싶습니다. 이 문제는 아직 해결되지 않았습니다. 그래서 교육을 위해 어드바이저/GUI를 도킹하는 작업을 제안한 것입니다. 상업적인 관심이 있고 대중의 아이디어를 수집하고 싶었습니다.
다이어그램에서 강조 표시된 구성 요소 내부에는 원하는 수의 모듈이 있을 수 있습니다. 이건 괜찮아. 나는 그들의 명확한 컨베이어 배열만이 유용하다고 생각합니다. 절대적으로 불가피한 경우 없이 코드 내부에서 혼동되어서는 안 됩니다. 저것들. 혼합은 가능한 한 피해야 합니다. 이를 통해 다중 기기 방향으로 확장할 때 모듈에 대해 항상 잘 정의되고 편리한 도킹 지점을 가질 수 있습니다. 이 각도에서 다이어그램을 보면 스스로 찾을 수 있습니다.
무한한 모듈 성장은 미래에 심각한 문제로 이어집니다. Expert Advisor의 논리는 실제로 다른 모듈에 분산되어 있습니다. 모듈 자체는 서로 상호 작용하며 모듈 간의 연결이 얽힌 엉킴으로 바뀌지 않는다는 보장은 없습니다. IMHO, 녹색으로 표시된 모든 사각형은 하나의 거래 시스템의 요소입니다. 그것들이 다른 모듈로 분해될 때, 프로그래밍의 주요 원칙 중 하나인 단일 작업 내에서 데이터와 메소드의 캡슐화를 위반합니다.
모두가 회로도를 게시하기 시작했기 때문에 나도 계속할 것입니다. 이번에는 더욱 추상적인 계획:
검은색 화살표는 엄격한 관계를 나타냅니다. 회색 - 모듈 내 사적인 관계, 중요하지 않습니다. 또한 거래 로봇 클래스는 플랫폼 API에 직접 접근할 수 있는 권한을 가지지만 이는 플랫폼 독립성을 감소시킨다.
무한한 모듈 성장은 미래에 심각한 문제로 이어집니다. Expert Advisor의 논리는 실제로 다른 모듈에 분산되어 있습니다. 모듈 자체는 서로 상호 작용하며 모듈 간의 연결이 얽힌 엉킴으로 바뀌지 않는다는 보장은 없습니다. IMHO, 녹색으로 표시된 모든 사각형은 하나의 거래 시스템의 요소입니다. 그것들이 다른 모듈로 분해될 때, 프로그래밍의 주요 원칙 중 하나인 단일 작업 내에서 데이터와 메소드의 캡슐화를 위반합니다.
모두가 회로도를 게시하기 시작했기 때문에 나도 계속할 것입니다. 이번에는 더 추상적인 계획:
검은색 화살표는 엄격한 관계를 나타냅니다. 회색 - 모듈 내 사적인 관계, 중요하지 않습니다. 또한 거래 로봇 클래스는 플랫폼 API에 직접 접근할 수 있는 권한을 가지지만 이는 플랫폼 독립성을 감소시킨다.
변경 개선을 희생하면서 (끓게 두십시오) 생각합니다.
결핍은 더 분명합니다. 이 체계에는 GUI(시각적 모니터링/제어 하위 시스템)가 분명히 부족합니다. EA와 GUI 간의 통합된 (편리한!) 상호 작용 방식을 개발하고 싶습니다. 지금까지 나는 이 문제에 대해 자발성을 가지고 있는데, 이는 정말로 나를 짜증나게 한다. 동일한 목표(양방향으로 완전한 데이터 추상화)를 달성하고 싶습니다. 이 문제는 아직 해결되지 않았습니다. 그래서 교육을 위해 어드바이저/GUI를 도킹하는 작업을 제안한 것입니다. 상업적인 관심이 있고 대중의 아이디어를 수집하고 싶었습니다.
작업에서 벗어나십시오. GUI에서 가장 수요가 많은 작업은 무엇입니까? 당신은 개인적으로.
거기에서 춤을. 얻고자 하는 것을 설명하고, 일반적인 단점을 강조 표시하고, 스켈레톤을 만든 다음, 다른 것을 추가하고, 스켈레톤을 변경하는 것이 얼마나 쉬운지 확인하십시오.
그러면 그것이 무엇인지 이해하고 모든 것을 다시 작성하십시오. 나는 이렇게 본다.
MetaDriver 는 모든 것을 올바르게 말하고 그의 시스템은 정확합니다. Fuck_fx는 또한 "거래 드라이버"가 최고의 가격을 사용하기 위해 10-20개 플랫폼에서 작동해야 한다고 덧붙였습니다.
그러나 전략에 오류가없고, 사용자 개입이없고, 불가항력이없는 이상적인 조건에서만 이러한 올바른 시스템을 사용하는 것이 편리합니다. 그러나 실제로는 거의 발생하지 않습니다.
나는 Horseradish_fx의 예를 확장할 것입니다: 25개의 전략이 작동하고, 애그리게이터(거래 동인)가 그것들을 순 위치에서 수집하고 시장에 가져옵니다. 모든 것이 정상입니다. 갑자기 17번째 전략에서 무언가가 중단되고 건강에 좋지 않은 예측이 나옵니다. 창고의 50%에서 열린다고 합니다. 고문은 순순히 열립니다.
MT4의 평범한 사물함의 기능은 다음과 같습니다.
이제 "정확한 회계"로 넘어 갑시다. 오류를 제거하기 위해 거래자는 무엇을 해야 합니까(50% 마진 거래는 논리상의 명백한 오류입니다):
질문: 어느 것이 더 쉽습니까? 분명히, MT4의 옵션입니다.
그리고 무엇이 더 싼가요? 분명히 Netting이 있는 변형입니다.
결론은 무엇입니까? MT4 GUI로 마켓 드라이버 만들기 ;)
그리고 여전히 추적 중입니다.
이것들은 모두 "올바른" 거래자들과 심지어 프로그래머들의 주장입니다. 예, 자신을 위해 사랑하는 사람을 위해 좋은 예금이있는 계정에 대한 경우 이것이 유일한 방법입니다.
그리고 우리가 전문적인 글쓰기를 만진다면 아무도 그것을 "올바르게" 필요로 하지 않는다는 것이 밝혀졌습니다. 상인-고객의 군중은 다시 만들 수 없으므로 "그들을 위해"라고 써야 합니다.
"직장 그만두기" 옵션이 허용됩니다! =)
그리고 여전히 추적 중입니다.
이것들은 모두 "올바른" 거래자들과 심지어 프로그래머들의 주장입니다. 예, 자신을 위해 사랑하는 사람을 위해 좋은 예금이있는 계정에 대한 경우 이것이 유일한 방법입니다.
그리고 우리가 전문적인 글쓰기를 만진다면 아무도 그것을 "올바르게" 필요로 하지 않는다는 것이 밝혀졌습니다. 상인-고객의 군중은 다시 만들 수 없으므로 "그들을 위해"라고 써야 합니다.
"직장 그만두기" 옵션이 허용됩니다! =)