아니요. 지금 단계에서는 그게 아닙니다. 구매에서 판매로 테스트하는 것은 시간 낭비일 수 있지만 그 반대의 경우도 마찬가지입니다. 내가 말할 때, 이것이 내가 의미한 바입니다.
가장 짧은 시간에 최상의 솔루션을 찾습니다. 동일한(매우 짧은) 시간 동안 최대 5-10분 동안 단위 논리당 테스트 하므로 논리가 결정될 수 있습니다. 99% 좋음 또는 99% 나쁨이 거의 확인되었습니다.
1) 예를 들어 다음과 같이 1개의 마스터 로직을 사용합니다.
나머지를 모두 제거하면 다음과 같이 됩니다.
즉, 단위 논리당 - 매수와 매도를 동시에 테스트합니다. 따라서 이 1개의 마스터 로직으로 최적화하려면 sl,tp, lot 등의 기본 매개변수에서만 최적화하면 됩니다. 그런 다음 매수 및 매도 사례를 분석하고 이 1가지 논리가 두 시나리오 모두에서 컷을 통과할 수 있는지 여부를 판단합니다. 둘 다. 그런 다음 다음 논리로 넘어갑니다.
잘 지내다 보면 조합을 시도해 볼 수 있습니다. 첫 번째 논리는 그냥 구매, 논리 2, 그냥 판매 또는 둘 다 등입니다. 이 방법이 더 구조화되어 있고 실제로 어떤 정확한 논리가 하락을 일으키는지 알 수 있습니다. .
나는 이 작업을 하는 동안 완전히 새로운 아이디어를 우연히 발견했습니다. 나는 꽤 기술적인 근거를 가지고 있었기 때문에 시장에서 일부 논리가 완전히 부정확/편향/결함이 있다고 쉽게 판단할 수 있었습니다.
하지만 저는 "이것이 정말로 사실이라면 어떻게 전략 테스터 에서 이를 증명할 수 있습니까? 분명히 방법이 있을 것입니다."라고 묻고 있었습니다. 그래서 우연히 이 방법을 택하게 되었습니다.
예를 들어 M240close< MA 240으로 시작하는 경우와 같이 검사 조건의 MA 논리를 하나씩 가져옵니다. 동시에 구매 및 판매 양쪽을 테스트합니다. 이제 다음과 같은 경우가 있습니다.
1) 이제 수학적으로 이 논리가 실제로 가능하다면 결과는 양쪽을 모두 포함하기 때문에 다소 중립적이어야 합니다. 동의하다? 수익성이 있는 것으로 판명되면 결과를 보고 구매 및 판매함으로써 결론을 내릴 수 있습니다. 이 논리는 반대 방향에서 펀치를 날리는 동안에도 컷을 아주 아주 잘 만들고 있습니다. 그래서 아주 건전합니다.
2) 이제 그것이 비참한 것으로 판명되면 전체 논리, 즉 240에서 종가와 MA 240을 비교하는 모든 종류의 시장 움직임에 대해 100% 결함이 있다는 결론을 내릴 수 있습니다. 따라서 전체 논리를 제거하고 완전히 교체해야 한다는 확신을 갖게 됩니다.
나머지는 최적화를 위해 tp, sl로 둡니다. 이 단계에서 더 중요한 것은 논리를 하나씩 수정하는 것입니다.
이 접근 방식을 사용한 이후로 저는 제 나름대로 상당한 진전을 이루었습니다. 이전에는 많은 사람들과 거의 동일한 작업을 수행했지만 이 새로운 방법으로 매우 짧은 시간에 심각한 진전을 이루고 있습니다..;-)
나는 이 작업을 하는 동안 완전히 새로운 아이디어를 우연히 발견했습니다. 나는 꽤 기술적인 근거를 가지고 있었기 때문에 시장에서 일부 논리가 완전히 부정확/편향/결함이 있다고 쉽게 판단할 수 있었습니다.
그러나 저는 "이것이 정말로 사실이라면 어떻게 전략 테스터에서 이를 증명할 수 있습니까? 확실히 방법이 있을 것입니다."라고 묻고 있었습니다. 그래서 우연히 이 방법을 택하게 되었습니다.
예를 들어 M240close< MA 240으로 시작하는 경우와 같이 검사 조건의 MA 논리를 하나씩 가져옵니다. 동시에 구매 및 판매 양쪽을 테스트합니다. 이제 다음과 같은 경우가 있습니다.
1) 이제 수학적으로 이 논리가 실제로 가능하다면 결과는 양쪽을 모두 포함하기 때문에 다소 중립적이어야 합니다. 동의하다? 수익성이 있는 것으로 판명되면 결과를 보고 구매 및 판매함으로써 결론을 내릴 수 있습니다. 이 논리는 반대 방향에서 펀치를 날리는 동안에도 컷을 아주 아주 잘 만들고 있습니다. 그래서 아주 건전합니다.
2) 이제 그것이 비참한 것으로 판명되면 전체 논리, 즉 240에서 종가와 MA 240을 비교하는 모든 종류의 시장 움직임에 대해 100% 결함이 있다는 결론을 내릴 수 있습니다. 따라서 전체 논리를 제거하고 완전히 교체해야 한다는 확신을 갖게 됩니다.
나머지는 최적화를 위해 tp, sl로 둡니다. 이 단계에서 더 중요한 것은 논리를 하나씩 수정하는 것입니다.
이 접근 방식을 사용한 이후로 저는 제 나름대로 상당한 진전을 이루었습니다. 이전에는 많은 사람들과 거의 동일한 작업을 수행했지만 이 새로운 방법으로 매우 짧은 시간에 심각한 진전을 이루고 있습니다..;-)
모든 변수를 동시에 최적화하지 않는 이유는 무엇입니까? 최적화 테스트를 실행하는 데 시간이 걸릴 수 있지만 컴퓨터가 2대 있는 이유입니다. 하나는 테스트용, 하나는 개발용입니다.
예를 들어 SL, TP, Trailing SL, Increment, Stack, Risk, 많은 거래 시간, 이메일, 보고, 청산 주문, 여러 쌍에서 작동하는 등 제대로 작동하는 쉘 EA가 있다고 가정합니다. 이 모든 것이 제대로 작동한다고 가정합니다. , 사소한 작업이 아니므로 거래를 입력하는 데 사용하는 논리가 무엇이든 남게 됩니다. 제 경우에는 1,0 또는 -1을 반환하는 Trade()가 있습니다. Trade()의 논리는 플러그인하려는 시스템이 될 수 있습니다.
먼저 비주얼 모드에서 거래 논리\시스템을 테스트하여 논리가 제대로 작동하는지 확인합니다. 예를 들어 정류장이 올바른 위치에 설정되어 있고 항목이 올바른 장소\바\레벨에 있으며 시스템에서 요구하는 모든 것이 있습니다. . 일단 완료되면, 완전히 정신을 잃은 경우가 아니라면 일반적으로 1시간 정도 테스트가 필요합니다. 그런 다음 TP, SL 스택, 거래 시간 및 거래 논리 Ma, 막대 패턴 내에서 테스트해야 하는 모든 변수에 대해 전체 최적화를 실행합니다.
모든 최적화를 동시에 실행하면 전략이 작동하는지 더 나은 아이디어를 얻을 수 있습니다. 테스트 시간을 줄이고 싶다면 시스템을 맛보기 위해 1-2개월과 같이 더 짧은 기간 동안 실행하십시오. 범위를 낮추면 4-8시간 정도가 소요되지 않습니다. 유망해 보인다면 시스템이 어떻게 작동하는지에 대한 실제 감각을 제공할 실제 백테스트를 실행하십시오. 백테스트는 이미 패자처럼 보이기 때문에 100회 실행 후에 백테스트를 멈출 수 없다는 말은 없습니다.
내 테스트에서 나는 드로다운을 최고의 통계로 보고 있습니다. 내 EA가 2%의 위험으로 12% 이상을 드로우하면 어쨌든 1원으로 돌아갑니다. 그것이 잘되면 나는 승/손실 퍼센트와 평균 승 대 평균 손실 비율을 봅니다. 나는 당신이 당신의 방식으로 그 숫자를 더 빨리 얻을 것이라고 확신하지 못합니다. 대부분의 경우 내 선택 실행의 80-90%가 계정을 0으로 낮추지 않으면 수익성 있는 EA에 대한 적절한 기회가 있습니다. 그런 다음 중간 수익 실행을 취하고 평균을 내고 더 작은 범위로 다시 최적화하여 라이브 데이터에 대한 순방향 테스트를 위한 설정을 얻습니다. 그것만으로도 한 달이 걸릴 수 있습니다. 그렇게 하지 않는 한 나는 진짜 돈으로 뛰지 않을 것입니다.
위의 모든 것을 무시하고 이것은 적어도 EA에서 개발 작업을 수행하는 방식입니다.
1, 2에 동의하지 않습니다.
1) 가능한 모든 변수를 사용하여 백테스터를 통해 옵트 실행을 실행하지 않는 한 시스템이 수익성이 있는지 여부를 증명하거나 알 수 없다고 생각합니다. What if, SL,TP,Stack, Stack 사이의 거리, 또는 MoveStop이 전략을 승자로 만드는 것, 그것은 실제로 what if가 아니라 사실입니다. 당신이 당신의 방식을 테스트하는 경우에도 승패를 보기 위해 SP나 TP 또는 무엇이든 필요합니다. 1분 차트에 100핍 SL이 있는 경우 85 -> 98%의 승률을 보이는 훌륭한 시스템을 갖게 될 가능성이 가장 큽니다. 최적화 실행을 통해 실행할 때 그런 식으로 수행되지 않을 것이라고 말할 수 있습니다. 30%의 승률과 매우 수익성 있는 EA를 가질 수 있습니다. 당신은 또한 90%의 승률을 가질 수 있고 드로다운은 70%가 될 수 있으며 4000개의 옵트 실행 중 3000개가 계정을 고갈시킵니다. 결국 당신은 어쨌든 전체 실행을 할 것입니다. 먼저 이를 수행하고 새 시스템을 병렬로 코딩하지 않는 이유는 무엇입니까?
2) 그것은 재앙으로 바뀔 수 있고 완전한 테스트 없이 시스템을 던질 수 있습니다. 그것은 당신이 방금 파워볼 번호를 확인했고 당신이 대박을 터뜨리지 않았다는 것을 알기 때문에 당첨된 파워볼 티켓을 쓰레기통에 던지는 것과 같을 수 있습니다. 당신은 다른 5개의 숫자를 가지고 있었고 방금 250,000명의 우승자를 쓰레기통에 던졌습니다. 이제 일부 비둘기는 정말 비싼 둥지를 가지고 있습니다.
결론 은 시스템의 실제 코딩이 개발 프로세스에서 가장 시간이 적게 걸리는 부분이라고 생각합니다. 테스트는 가장 길고 중요한 부분이며 테스트 단계에서 대부분의 시간을 보내고 싶습니다. 나는 또한 실패한 EA로부터 더 많은 것을 배우는 경향이 있습니다. 이것이 모두가 말하는 것이라는 것을 압니다. 그러나 테스트의 실패는 향후 최적화를 위해 매개변수 범위를 좁히는 데 도움이 되는 경향이 있습니다. 이것은 결국 더 유망한 EA의 테스트를 더 빠르게 만듭니다.
모든 변수를 동시에 최적화하지 않는 이유는 무엇입니까? 최적화 테스트를 실행하는 데 시간이 걸릴 수 있지만 컴퓨터가 2대 있는 이유입니다. 하나는 테스트용, 하나는 개발용입니다.
예를 들어 SL, TP, Trailing SL, Increment, Stack, Risk, 많은 거래 시간, 이메일, 보고, 청산 주문, 여러 쌍에서 작동하는 등 제대로 작동하는 쉘 EA가 있다고 가정합니다. 이 모든 것이 제대로 작동한다고 가정합니다. , 사소한 작업이 아니므로 거래를 입력하는 데 사용하는 논리가 무엇이든 남게 됩니다. 제 경우에는 1,0 또는 -1을 반환하는 Trade()가 있습니다. Trade()의 논리는 플러그인하려는 시스템이 될 수 있습니다.
먼저 비주얼 모드에서 거래 논리\시스템을 테스트하여 논리가 제대로 작동하는지 확인합니다. 예를 들어 정류장이 올바른 위치에 설정되어 있고 항목이 올바른 장소\바\레벨에 있으며 시스템에서 요구하는 모든 것이 있습니다. . 일단 완료되면, 완전히 정신을 잃은 경우가 아니라면 일반적으로 1시간 정도 테스트가 필요합니다. 그런 다음 TP, SL 스택, 거래 시간 및 거래 논리 Ma, 막대 패턴 내에서 테스트해야 하는 모든 변수에 대해 전체 최적화를 실행합니다.
모든 최적화를 동시에 실행하면 전략이 작동하는지 더 나은 아이디어를 얻을 수 있습니다. 테스트 시간을 줄이고 싶다면 시스템을 맛보기 위해 1-2개월과 같이 더 짧은 기간 동안 실행하십시오. 범위를 낮추면 4-8시간 정도가 소요되지 않습니다. 유망해 보인다면 시스템이 어떻게 작동하는지에 대한 실제 감각을 제공할 실제 백테스트를 실행하십시오. 백테스트는 이미 패자처럼 보이기 때문에 100회 실행 후에 백테스트를 멈출 수 없다는 말은 없습니다.
내 테스트에서 나는 드로다운을 최고의 통계로 보고 있습니다. 내 EA가 2%의 위험으로 12% 이상을 드로우하면 어쨌든 1원으로 돌아갑니다. 그것이 잘되면 나는 승/손실 퍼센트와 평균 승 대 평균 손실 비율을 봅니다. 나는 당신이 당신의 방식으로 그 숫자를 더 빨리 얻을 것이라고 확신하지 못합니다. 대부분의 경우 내 선택 실행의 80-90%가 계정을 0으로 낮추지 않으면 수익성 있는 EA에 대한 적절한 기회가 있습니다. 그런 다음 중간 수익 실행을 취하고 평균을 내고 더 작은 범위로 다시 최적화하여 라이브 데이터에 대한 순방향 테스트를 위한 설정을 얻습니다. 그것만으로도 한 달이 걸릴 수 있습니다. 그렇게 하지 않는 한 나는 진짜 돈으로 뛰지 않을 것입니다.
위의 모든 것을 무시하고 이것은 적어도 EA에서 개발 작업을 수행하는 방식입니다.
1, 2에 동의하지 않습니다.
1) 가능한 모든 변수를 사용하여 백테스터를 통해 옵트 실행을 실행하지 않는 한 시스템이 수익성이 있는지 여부를 증명하거나 알 수 없다고 생각합니다. What if, SL,TP,Stack, Stack 사이의 거리, 또는 MoveStop이 전략을 승자로 만드는 것, 그것은 실제로 what if가 아니라 사실입니다. 당신이 당신의 방식을 테스트하는 경우에도 승패를 보기 위해 SP나 TP 또는 무엇이든 필요합니다. 1분 차트에 100핍 SL이 있는 경우 85 -> 98%의 승률을 보이는 훌륭한 시스템을 갖게 될 가능성이 가장 큽니다. 최적화 실행을 통해 실행할 때 그런 식으로 수행되지 않을 것이라고 말할 수 있습니다. 30%의 승률과 매우 수익성 있는 EA를 가질 수 있습니다. 당신은 또한 90%의 승률을 가질 수 있고 드로다운은 70%가 될 수 있으며 4000개의 옵트 실행 중 3000개가 계정을 고갈시킵니다. 결국 당신은 어쨌든 전체 실행을 할 것입니다. 먼저 이를 수행하고 새 시스템을 병렬로 코딩하지 않는 이유는 무엇입니까?
2) 그것은 재앙으로 바뀔 수 있고 완전한 테스트 없이 시스템을 던질 수 있습니다. 그것은 당신이 방금 파워볼 번호를 확인했고 당신이 대박을 터뜨리지 않았다는 것을 알기 때문에 당첨된 파워볼 티켓을 쓰레기통에 던지는 것과 같을 수 있습니다. 당신은 다른 5개의 숫자를 가지고 있었고 방금 250,000명의 우승자를 쓰레기통에 던졌습니다. 이제 일부 비둘기는 정말 비싼 둥지를 가지고 있습니다.
결론은 시스템의 실제 코딩이 개발 프로세스에서 가장 시간이 적게 걸리는 부분이라고 생각합니다. 테스트는 가장 길고 중요한 부분이며 테스트 단계에서 대부분의 시간을 보내고 싶습니다. 나는 또한 실패한 EA로부터 더 많은 것을 배우는 경향이 있습니다. 이것이 모두가 말하는 것이라는 것을 압니다. 그러나 테스트의 실패는 향후 최적화를 위해 매개변수 범위를 좁히는 데 도움이 되는 경향이 있습니다. 이것은 결국 더 유망한 EA의 테스트를 더 빠르게 만듭니다.
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성 이 나온다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그렇게 쉬웠다면 더 좋은 방법을 찾지 않았을 것입니다.
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성이 있습니다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그게 그렇게 쉬웠다면 나는 더 나은 방법을 찾지 않았을 것입니다.
이 요점은 기사가 최적화에 대해 가지고 있던 것과 정확히 같습니다. 그리고 테스터에 대한 제 개인적인 견해도 있습니다. 나는 왜 다른 것을 조언했는지에 대해 매우 놀랐습니다. 비즈니스 모순?
이 사실을 고려한다면 대체로 거래는 비교적 "단순한" 게임입니다. 아무도, 심지어 천재적인 로봇도 일부 로봇처럼 하루 종일 거래를 하지 않습니다. 훌륭하고 뛰어난 로봇은 15-30분, 최대 1시간이면 들어가고 70-100핍의 흔적을 남기고 점심을 먹으러 갑니다. 로봇 치고는 충분히 어려운 소리입니까? 매주 또는 매일 할 수 있고 YTE의 그 할머니처럼 늙을 때까지 하는 것을 좋아한다면 그것을 성배라고 부릅니다. 영원히 땜질해야 하는 로봇이 아닙니다.
그러나 아마도 당신은 로봇으로 일을 복잡하게 만들고 시장 외에 실제로 컴퓨터 프로그램을 움직이는 것이 무엇인지에 대한 특정 노하우를 손끝에서 가질 준비를 하고 싶을 것입니다. 프로그래밍뿐만 아니라 기본적인 주제도 다루는 능력이 필요할 수 있습니다. 부울 논리는 확실한 것, 수학 및 엔지니어링 통찰력이 도움이 될 것 등입니다. 이러한 능력은 일부 사람들을 넘어설 수 있습니다.
당신이 더 알고 싶다면, 내가 공유할 수 있는 것은 테스트와 최적화이며, 당신이 따르도록 한 어떤 논리에 의해 데이터를 휘젓는 영리한 기계적 통계적 힘에 지나지 않습니다. 그러나 진실은 시장이 통계적 법칙이나 당신의 논리에 따라 작동하지 않는다는 것입니다. 아직 발견하지 못했다면 말입니다.
나는 만족스러운 백테스트 결과를 제공했지만 여전히 나에게 엄청나게 큰 손실을 주는 상업용 EA를 잘 추천했습니다. 지난 몇 달 동안. 이제, 당신이 그것을 경험했다면, 당신은 내가 의미하는 바를 더 잘 알 것입니다. 성배 같은 것이 있지만, 그 순간에 맞춰 땜질해야 하는 기계적인 것은 절대 아니다. 그리고 그 영광스러운 백테스트 결과.
제 충고는 이것입니다. 이 땜질을 취미로 하고 거래는 별도로 하십시오. 둘 다 결합하려면 장기적으로 그 자체의 희생이 될 준비를 하십시오.
당신이 당신을 함정에 빠뜨리면 최적화는 함정입니다. 저는 Optimization을 사용하여 몇 년 동안 가능한 한 많은 거래를 얻습니다. 다른 일을 하고 있는 동안. 나는 테스트, 백테스트 및 포워드 테스트를 거치지 않은 로봇에 내 돈을 투자하지 않을 것입니다. 문제는 시간, 실제 돈을 거래하기 위해 얼마나 기다려야 하는지입니다. 저는 5년 정도 거래를 해왔습니다. 휴먼보다 로봇의 장점은 이것이야말로 당신이 프로그래밍한 대로 하는 것입니다. 그것은 CNBC를 켜지 않고 어떤 바보의 생각에 귀를 기울이지 않으며, 새로운 릴리스를 기다리지 않으며, 시장이 회전할 것이라는 느낌을 가졌기 때문에 긴장하거나 일찍 거래를 중단하지 않습니다. 풀 타임 트레이더가 아닌 경우에도 작동합니다.
옵티마이저에서 12,000개의 시뮬레이션을 실행하고 그 실행 중 70%가 실패하고 실행의 10%가 2000%를 얻거나 사람들이 찾고 있는 미친 숫자를 얻는다면 시스템이 거의 손실되고 테스트할 가치가 없습니다. .
수년에 걸쳐 수동으로 시스템을 테스트하고 매 실행 후 한 번에 하나의 매개변수를 변경하여 시스템을 조정할 것이라고 생각한다면 최적화 프로그램을 실행하는 것보다 더 미친 짓입니다. 그러나 opt에서 15,000개의 패스를 실행하고 그 패스 중 어느 것도 패자가 아닌 경우 4주 동안 포워드 테스트를 위해 최소한 데모 계정에 들어갈 준비가 된 시스템이 있는 것입니다. BTW 이 시점에서 실제 코딩 버그를 찾을 것입니다.
하루에 15~30분 거래하고 100~150핍을 은행에 넣고 점심을 먹는 사람을 보여주세요. 실제 돈을 거래하지 않는 사람을 보여드리겠습니다. 무역은 다른 직업과 마찬가지로 정규직입니다.
이것이 취미라면 왜 이런 종류의 코딩에 시간을 낭비하는지 모르겠습니다. 기술적으로 매우 쉽고 일반적인 개발 작업에서만큼 많은 돈을 벌지 못할 것입니다. 저는 4개의 언어를 사용하는 2백만 라인에 가까운 코드가 있고 메인프레임, PC, UNIX 및 대부분의 Linux 운영 체제의 모든 버전에서 실행되는 일상 업무의 시스템에서 작업합니다.
제 겸손한 의견으로는 기사가 흥미로웠습니다. 그렇다고 해서 그 안에 있는 모든 단어를 믿는 것은 아닙니다. 작성자의 의견일 뿐입니다. 최적화가 함정이라는 결론에 도달하기 위해 많은 최적화를 실행해야 했을 것입니다. 그들이 그렇게했다면 최적화가 작동하지 않기 때문에 기사가 어떻게 정확할 수 있습니까?
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성 이 나온다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그렇게 쉬웠다면 더 좋은 방법을 찾지 않았을 것입니다.
백 테스팅은 논리(기술적, 시각적)를 테스트하는 데만 유용하며 수익 잠재력의 척도로 사용되어서는 안 됩니다.
따라서 성능을 측정하기 위해 테스트 EA만 전달하므로 최적화와 같은 것은 완전히 새로운 주제이며 여전히 회의적입니다.
수년에 걸쳐 수동으로 시스템을 테스트하고 매 실행 후 한 번에 하나의 매개변수를 변경하여 시스템을 조정할 것이라고 생각한다면 최적화 프로그램을 실행하는 것보다 더 미친 짓입니다. 그러나 opt에서 15,000개의 패스를 실행하고 그 패스 중 어느 것도 패자가 아닌 경우 4주 동안 포워드 테스트를 위해 최소한 데모 계정에 들어갈 준비가 된 시스템이 있는 것입니다. BTW 이 시점에서 실제 코딩 버그를 찾을 것입니다.
아니요. 지금 단계에서는 그게 아닙니다. 구매에서 판매로 테스트하는 것은 시간 낭비일 수 있지만 그 반대의 경우도 마찬가지입니다. 내가 말할 때, 이것이 내가 의미한 바입니다.
가장 짧은 시간에 최상의 솔루션을 찾습니다. 동일한(매우 짧은) 시간 동안 최대 5-10분 동안 단위 논리당 테스트 하므로 논리가 결정될 수 있습니다. 99% 좋음 또는 99% 나쁨이 거의 확인되었습니다.
1) 예를 들어 다음과 같이 1개의 마스터 로직을 사용합니다.
나머지를 모두 제거하면 다음과 같이 됩니다.
즉, 단위 논리당 - 매수와 매도를 동시에 테스트합니다. 따라서 이 1개의 마스터 로직으로 최적화하려면 sl,tp, lot 등의 기본 매개변수에서만 최적화하면 됩니다. 그런 다음 매수 및 매도 사례를 분석하고 이 1가지 논리가 두 시나리오 모두에서 컷을 통과할 수 있는지 여부를 판단합니다. 둘 다. 그런 다음 다음 논리로 넘어갑니다.
잘 지내다 보면 조합을 시도해 볼 수 있습니다. 첫 번째 논리는 그냥 구매, 논리 2, 그냥 판매 또는 둘 다 등입니다. 이 방법이 더 구조화되어 있고 실제로 어떤 정확한 논리가 하락을 일으키는지 알 수 있습니다. .
나는 이러한 방법으로 EA를 테스트 한 적이 없으므로 나와 함께 pls ...
제 질문은 수익에만 집중하기 위해 어떤 매개변수 를 분리해야 하는지입니다.
나는 이러한 방법으로 EA를 테스트 한 적이 없으므로 나와 함께 pls ...
제 질문은 수익에만 집중하기 위해 어떤 매개변수를 분리해야 하는지입니다.
나는 이 작업을 하는 동안 완전히 새로운 아이디어를 우연히 발견했습니다. 나는 꽤 기술적인 근거를 가지고 있었기 때문에 시장에서 일부 논리가 완전히 부정확/편향/결함이 있다고 쉽게 판단할 수 있었습니다.
하지만 저는 "이것이 정말로 사실이라면 어떻게 전략 테스터 에서 이를 증명할 수 있습니까? 분명히 방법이 있을 것입니다."라고 묻고 있었습니다. 그래서 우연히 이 방법을 택하게 되었습니다.
예를 들어 M240close< MA 240으로 시작하는 경우와 같이 검사 조건의 MA 논리를 하나씩 가져옵니다. 동시에 구매 및 판매 양쪽을 테스트합니다. 이제 다음과 같은 경우가 있습니다.
1) 이제 수학적으로 이 논리가 실제로 가능하다면 결과는 양쪽을 모두 포함하기 때문에 다소 중립적이어야 합니다. 동의하다? 수익성이 있는 것으로 판명되면 결과를 보고 구매 및 판매함으로써 결론을 내릴 수 있습니다. 이 논리는 반대 방향에서 펀치를 날리는 동안에도 컷을 아주 아주 잘 만들고 있습니다. 그래서 아주 건전합니다.
2) 이제 그것이 비참한 것으로 판명되면 전체 논리, 즉 240에서 종가와 MA 240을 비교하는 모든 종류의 시장 움직임에 대해 100% 결함이 있다는 결론을 내릴 수 있습니다. 따라서 전체 논리를 제거하고 완전히 교체해야 한다는 확신을 갖게 됩니다.
나머지는 최적화를 위해 tp, sl로 둡니다. 이 단계에서 더 중요한 것은 논리를 하나씩 수정하는 것입니다.
이 접근 방식을 사용한 이후로 저는 제 나름대로 상당한 진전을 이루었습니다. 이전에는 많은 사람들과 거의 동일한 작업을 수행했지만 이 새로운 방법으로 매우 짧은 시간에 심각한 진전을 이루고 있습니다..;-)
나는 이 작업을 하는 동안 완전히 새로운 아이디어를 우연히 발견했습니다. 나는 꽤 기술적인 근거를 가지고 있었기 때문에 시장에서 일부 논리가 완전히 부정확/편향/결함이 있다고 쉽게 판단할 수 있었습니다.
그러나 저는 "이것이 정말로 사실이라면 어떻게 전략 테스터에서 이를 증명할 수 있습니까? 확실히 방법이 있을 것입니다."라고 묻고 있었습니다. 그래서 우연히 이 방법을 택하게 되었습니다.
예를 들어 M240close< MA 240으로 시작하는 경우와 같이 검사 조건의 MA 논리를 하나씩 가져옵니다. 동시에 구매 및 판매 양쪽을 테스트합니다. 이제 다음과 같은 경우가 있습니다.
1) 이제 수학적으로 이 논리가 실제로 가능하다면 결과는 양쪽을 모두 포함하기 때문에 다소 중립적이어야 합니다. 동의하다? 수익성이 있는 것으로 판명되면 결과를 보고 구매 및 판매함으로써 결론을 내릴 수 있습니다. 이 논리는 반대 방향에서 펀치를 날리는 동안에도 컷을 아주 아주 잘 만들고 있습니다. 그래서 아주 건전합니다.
2) 이제 그것이 비참한 것으로 판명되면 전체 논리, 즉 240에서 종가와 MA 240을 비교하는 모든 종류의 시장 움직임에 대해 100% 결함이 있다는 결론을 내릴 수 있습니다. 따라서 전체 논리를 제거하고 완전히 교체해야 한다는 확신을 갖게 됩니다.
나머지는 최적화를 위해 tp, sl로 둡니다. 이 단계에서 더 중요한 것은 논리를 하나씩 수정하는 것입니다.
이 접근 방식을 사용한 이후로 저는 제 나름대로 상당한 진전을 이루었습니다. 이전에는 많은 사람들과 거의 동일한 작업을 수행했지만 이 새로운 방법으로 매우 짧은 시간에 심각한 진전을 이루고 있습니다..;-)
모든 변수를 동시에 최적화하지 않는 이유는 무엇입니까? 최적화 테스트를 실행하는 데 시간이 걸릴 수 있지만 컴퓨터가 2대 있는 이유입니다. 하나는 테스트용, 하나는 개발용입니다.
예를 들어 SL, TP, Trailing SL, Increment, Stack, Risk, 많은 거래 시간, 이메일, 보고, 청산 주문, 여러 쌍에서 작동하는 등 제대로 작동하는 쉘 EA가 있다고 가정합니다. 이 모든 것이 제대로 작동한다고 가정합니다. , 사소한 작업이 아니므로 거래를 입력하는 데 사용하는 논리가 무엇이든 남게 됩니다. 제 경우에는 1,0 또는 -1을 반환하는 Trade()가 있습니다. Trade()의 논리는 플러그인하려는 시스템이 될 수 있습니다.
먼저 비주얼 모드에서 거래 논리\시스템을 테스트하여 논리가 제대로 작동하는지 확인합니다. 예를 들어 정류장이 올바른 위치에 설정되어 있고 항목이 올바른 장소\바\레벨에 있으며 시스템에서 요구하는 모든 것이 있습니다. . 일단 완료되면, 완전히 정신을 잃은 경우가 아니라면 일반적으로 1시간 정도 테스트가 필요합니다. 그런 다음 TP, SL 스택, 거래 시간 및 거래 논리 Ma, 막대 패턴 내에서 테스트해야 하는 모든 변수에 대해 전체 최적화를 실행합니다.
모든 최적화를 동시에 실행하면 전략이 작동하는지 더 나은 아이디어를 얻을 수 있습니다. 테스트 시간을 줄이고 싶다면 시스템을 맛보기 위해 1-2개월과 같이 더 짧은 기간 동안 실행하십시오. 범위를 낮추면 4-8시간 정도가 소요되지 않습니다. 유망해 보인다면 시스템이 어떻게 작동하는지에 대한 실제 감각을 제공할 실제 백테스트를 실행하십시오. 백테스트는 이미 패자처럼 보이기 때문에 100회 실행 후에 백테스트를 멈출 수 없다는 말은 없습니다.
내 테스트에서 나는 드로다운을 최고의 통계로 보고 있습니다. 내 EA가 2%의 위험으로 12% 이상을 드로우하면 어쨌든 1원으로 돌아갑니다. 그것이 잘되면 나는 승/손실 퍼센트와 평균 승 대 평균 손실 비율을 봅니다. 나는 당신이 당신의 방식으로 그 숫자를 더 빨리 얻을 것이라고 확신하지 못합니다. 대부분의 경우 내 선택 실행의 80-90%가 계정을 0으로 낮추지 않으면 수익성 있는 EA에 대한 적절한 기회가 있습니다. 그런 다음 중간 수익 실행을 취하고 평균을 내고 더 작은 범위로 다시 최적화하여 라이브 데이터에 대한 순방향 테스트를 위한 설정을 얻습니다. 그것만으로도 한 달이 걸릴 수 있습니다. 그렇게 하지 않는 한 나는 진짜 돈으로 뛰지 않을 것입니다.
위의 모든 것을 무시하고 이것은 적어도 EA에서 개발 작업을 수행하는 방식입니다.
1, 2에 동의하지 않습니다.
1) 가능한 모든 변수를 사용하여 백테스터를 통해 옵트 실행을 실행하지 않는 한 시스템이 수익성이 있는지 여부를 증명하거나 알 수 없다고 생각합니다. What if, SL,TP,Stack, Stack 사이의 거리, 또는 MoveStop이 전략을 승자로 만드는 것, 그것은 실제로 what if가 아니라 사실입니다. 당신이 당신의 방식을 테스트하는 경우에도 승패를 보기 위해 SP나 TP 또는 무엇이든 필요합니다. 1분 차트에 100핍 SL이 있는 경우 85 -> 98%의 승률을 보이는 훌륭한 시스템을 갖게 될 가능성이 가장 큽니다. 최적화 실행을 통해 실행할 때 그런 식으로 수행되지 않을 것이라고 말할 수 있습니다. 30%의 승률과 매우 수익성 있는 EA를 가질 수 있습니다. 당신은 또한 90%의 승률을 가질 수 있고 드로다운은 70%가 될 수 있으며 4000개의 옵트 실행 중 3000개가 계정을 고갈시킵니다. 결국 당신은 어쨌든 전체 실행을 할 것입니다. 먼저 이를 수행하고 새 시스템을 병렬로 코딩하지 않는 이유는 무엇입니까?
2) 그것은 재앙으로 바뀔 수 있고 완전한 테스트 없이 시스템을 던질 수 있습니다. 그것은 당신이 방금 파워볼 번호를 확인했고 당신이 대박을 터뜨리지 않았다는 것을 알기 때문에 당첨된 파워볼 티켓을 쓰레기통에 던지는 것과 같을 수 있습니다. 당신은 다른 5개의 숫자를 가지고 있었고 방금 250,000명의 우승자를 쓰레기통에 던졌습니다. 이제 일부 비둘기는 정말 비싼 둥지를 가지고 있습니다.
결론 은 시스템의 실제 코딩이 개발 프로세스에서 가장 시간이 적게 걸리는 부분이라고 생각합니다. 테스트는 가장 길고 중요한 부분이며 테스트 단계에서 대부분의 시간을 보내고 싶습니다. 나는 또한 실패한 EA로부터 더 많은 것을 배우는 경향이 있습니다. 이것이 모두가 말하는 것이라는 것을 압니다. 그러나 테스트의 실패는 향후 최적화를 위해 매개변수 범위를 좁히는 데 도움이 되는 경향이 있습니다. 이것은 결국 더 유망한 EA의 테스트를 더 빠르게 만듭니다.
그냥 내 2 센트.
모든 변수를 동시에 최적화하지 않는 이유는 무엇입니까? 최적화 테스트를 실행하는 데 시간이 걸릴 수 있지만 컴퓨터가 2대 있는 이유입니다. 하나는 테스트용, 하나는 개발용입니다.
예를 들어 SL, TP, Trailing SL, Increment, Stack, Risk, 많은 거래 시간, 이메일, 보고, 청산 주문, 여러 쌍에서 작동하는 등 제대로 작동하는 쉘 EA가 있다고 가정합니다. 이 모든 것이 제대로 작동한다고 가정합니다. , 사소한 작업이 아니므로 거래를 입력하는 데 사용하는 논리가 무엇이든 남게 됩니다. 제 경우에는 1,0 또는 -1을 반환하는 Trade()가 있습니다. Trade()의 논리는 플러그인하려는 시스템이 될 수 있습니다.
먼저 비주얼 모드에서 거래 논리\시스템을 테스트하여 논리가 제대로 작동하는지 확인합니다. 예를 들어 정류장이 올바른 위치에 설정되어 있고 항목이 올바른 장소\바\레벨에 있으며 시스템에서 요구하는 모든 것이 있습니다. . 일단 완료되면, 완전히 정신을 잃은 경우가 아니라면 일반적으로 1시간 정도 테스트가 필요합니다. 그런 다음 TP, SL 스택, 거래 시간 및 거래 논리 Ma, 막대 패턴 내에서 테스트해야 하는 모든 변수에 대해 전체 최적화를 실행합니다.
모든 최적화를 동시에 실행하면 전략이 작동하는지 더 나은 아이디어를 얻을 수 있습니다. 테스트 시간을 줄이고 싶다면 시스템을 맛보기 위해 1-2개월과 같이 더 짧은 기간 동안 실행하십시오. 범위를 낮추면 4-8시간 정도가 소요되지 않습니다. 유망해 보인다면 시스템이 어떻게 작동하는지에 대한 실제 감각을 제공할 실제 백테스트를 실행하십시오. 백테스트는 이미 패자처럼 보이기 때문에 100회 실행 후에 백테스트를 멈출 수 없다는 말은 없습니다.
내 테스트에서 나는 드로다운을 최고의 통계로 보고 있습니다. 내 EA가 2%의 위험으로 12% 이상을 드로우하면 어쨌든 1원으로 돌아갑니다. 그것이 잘되면 나는 승/손실 퍼센트와 평균 승 대 평균 손실 비율을 봅니다. 나는 당신이 당신의 방식으로 그 숫자를 더 빨리 얻을 것이라고 확신하지 못합니다. 대부분의 경우 내 선택 실행의 80-90%가 계정을 0으로 낮추지 않으면 수익성 있는 EA에 대한 적절한 기회가 있습니다. 그런 다음 중간 수익 실행을 취하고 평균을 내고 더 작은 범위로 다시 최적화하여 라이브 데이터에 대한 순방향 테스트를 위한 설정을 얻습니다. 그것만으로도 한 달이 걸릴 수 있습니다. 그렇게 하지 않는 한 나는 진짜 돈으로 뛰지 않을 것입니다.
위의 모든 것을 무시하고 이것은 적어도 EA에서 개발 작업을 수행하는 방식입니다.
1, 2에 동의하지 않습니다.
1) 가능한 모든 변수를 사용하여 백테스터를 통해 옵트 실행을 실행하지 않는 한 시스템이 수익성이 있는지 여부를 증명하거나 알 수 없다고 생각합니다. What if, SL,TP,Stack, Stack 사이의 거리, 또는 MoveStop이 전략을 승자로 만드는 것, 그것은 실제로 what if가 아니라 사실입니다. 당신이 당신의 방식을 테스트하는 경우에도 승패를 보기 위해 SP나 TP 또는 무엇이든 필요합니다. 1분 차트에 100핍 SL이 있는 경우 85 -> 98%의 승률을 보이는 훌륭한 시스템을 갖게 될 가능성이 가장 큽니다. 최적화 실행을 통해 실행할 때 그런 식으로 수행되지 않을 것이라고 말할 수 있습니다. 30%의 승률과 매우 수익성 있는 EA를 가질 수 있습니다. 당신은 또한 90%의 승률을 가질 수 있고 드로다운은 70%가 될 수 있으며 4000개의 옵트 실행 중 3000개가 계정을 고갈시킵니다. 결국 당신은 어쨌든 전체 실행을 할 것입니다. 먼저 이를 수행하고 새 시스템을 병렬로 코딩하지 않는 이유는 무엇입니까?
2) 그것은 재앙으로 바뀔 수 있고 완전한 테스트 없이 시스템을 던질 수 있습니다. 그것은 당신이 방금 파워볼 번호를 확인했고 당신이 대박을 터뜨리지 않았다는 것을 알기 때문에 당첨된 파워볼 티켓을 쓰레기통에 던지는 것과 같을 수 있습니다. 당신은 다른 5개의 숫자를 가지고 있었고 방금 250,000명의 우승자를 쓰레기통에 던졌습니다. 이제 일부 비둘기는 정말 비싼 둥지를 가지고 있습니다.
결론은 시스템의 실제 코딩이 개발 프로세스에서 가장 시간이 적게 걸리는 부분이라고 생각합니다. 테스트는 가장 길고 중요한 부분이며 테스트 단계에서 대부분의 시간을 보내고 싶습니다. 나는 또한 실패한 EA로부터 더 많은 것을 배우는 경향이 있습니다. 이것이 모두가 말하는 것이라는 것을 압니다. 그러나 테스트의 실패는 향후 최적화를 위해 매개변수 범위를 좁히는 데 도움이 되는 경향이 있습니다. 이것은 결국 더 유망한 EA의 테스트를 더 빠르게 만듭니다.
그냥 내 2 센트.
글쎄요, 그럼 동의하지 않겠습니다. 그리고 정말 긴 글을 써주셔서 감사합니다. 아마도 이 기사가 그럴 것입니다. 최적화 = TRAP , 빠질 수 있습니다. https://www.mql5.com/en/articles/1434
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당 하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성 이 나온다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그렇게 쉬웠다면 더 좋은 방법을 찾지 않았을 것입니다.
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당 하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성이 있습니다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그게 그렇게 쉬웠다면 나는 더 나은 방법을 찾지 않았을 것입니다.
이 사실을 고려한다면 대체로 거래는 비교적 "단순한" 게임입니다. 아무도, 심지어 천재적인 로봇도 일부 로봇처럼 하루 종일 거래를 하지 않습니다. 훌륭하고 뛰어난 로봇은 15-30분, 최대 1시간이면 들어가고 70-100핍의 흔적을 남기고 점심을 먹으러 갑니다. 로봇 치고는 충분히 어려운 소리입니까? 매주 또는 매일 할 수 있고 YTE의 그 할머니처럼 늙을 때까지 하는 것을 좋아한다면 그것을 성배라고 부릅니다. 영원히 땜질해야 하는 로봇이 아닙니다.
그러나 아마도 당신은 로봇으로 일을 복잡하게 만들고 시장 외에 실제로 컴퓨터 프로그램을 움직이는 것이 무엇인지에 대한 특정 노하우를 손끝에서 가질 준비를 하고 싶을 것입니다. 프로그래밍뿐만 아니라 기본적인 주제도 다루는 능력이 필요할 수 있습니다. 부울 논리는 확실한 것, 수학 및 엔지니어링 통찰력이 도움이 될 것 등입니다. 이러한 능력은 일부 사람들을 넘어설 수 있습니다.
당신이 더 알고 싶다면, 내가 공유할 수 있는 것은 테스트와 최적화이며, 당신이 따르도록 한 어떤 논리에 의해 데이터를 휘젓는 영리한 기계적 통계적 힘에 지나지 않습니다. 그러나 진실은 시장이 통계적 법칙이나 당신의 논리에 따라 작동하지 않는다는 것입니다. 아직 발견하지 못했다면 말입니다.
나는 만족스러운 백테스트 결과를 제공했지만 여전히 나에게 엄청나게 큰 손실을 주는 상업용 EA를 잘 추천했습니다. 지난 몇 달 동안. 이제, 당신이 그것을 경험했다면, 당신은 내가 의미하는 바를 더 잘 알 것입니다. 성배 같은 것이 있지만, 그 순간에 맞춰 땜질해야 하는 기계적인 것은 절대 아니다. 그리고 그 영광스러운 백테스트 결과.
제 충고는 이것입니다. 이 땜질을 취미로 하고 거래는 별도로 하십시오. 둘 다 결합하려면 장기적으로 그 자체의 희생이 될 준비를 하십시오.
Forex를 거래하는 사람들의 99% 는 잃을 것입니다. 이들은 로봇이 아닌 거래자입니다. 로봇은 악이 아니라 도구 입니다. 로봇은 당신이 지불하는 돈과 시간만큼만 훌륭합니다. ;)
글쎄요, 그럼 동의하지 않겠습니다. 그리고 정말 긴 글을 써주셔서 감사합니다. 아마도 이 기사가 그럴 것입니다. 최적화 = TRAP , 빠질 수 있습니다. https://www.mql5.com/en/articles/1434
당신이 당신을 함정에 빠뜨리면 최적화는 함정입니다. 저는 Optimization을 사용하여 몇 년 동안 가능한 한 많은 거래를 얻습니다. 다른 일을 하고 있는 동안. 나는 테스트, 백테스트 및 포워드 테스트를 거치지 않은 로봇에 내 돈을 투자하지 않을 것입니다. 문제는 시간, 실제 돈을 거래하기 위해 얼마나 기다려야 하는지입니다. 저는 5년 정도 거래를 해왔습니다. 휴먼보다 로봇의 장점은 이것이야말로 당신이 프로그래밍한 대로 하는 것입니다. 그것은 CNBC를 켜지 않고 어떤 바보의 생각에 귀를 기울이지 않으며, 새로운 릴리스를 기다리지 않으며, 시장이 회전할 것이라는 느낌을 가졌기 때문에 긴장하거나 일찍 거래를 중단하지 않습니다. 풀 타임 트레이더가 아닌 경우에도 작동합니다.
옵티마이저에서 12,000개의 시뮬레이션을 실행하고 그 실행 중 70%가 실패하고 실행의 10%가 2000%를 얻거나 사람들이 찾고 있는 미친 숫자를 얻는다면 시스템이 거의 손실되고 테스트할 가치가 없습니다. .
수년에 걸쳐 수동으로 시스템을 테스트하고 매 실행 후 한 번에 하나의 매개변수를 변경하여 시스템을 조정할 것이라고 생각한다면 최적화 프로그램을 실행하는 것보다 더 미친 짓입니다. 그러나 opt에서 15,000개의 패스를 실행하고 그 패스 중 어느 것도 패자가 아닌 경우 4주 동안 포워드 테스트를 위해 최소한 데모 계정에 들어갈 준비가 된 시스템이 있는 것입니다. BTW 이 시점에서 실제 코딩 버그를 찾을 것입니다.
하루에 15~30분 거래하고 100~150핍을 은행에 넣고 점심을 먹는 사람을 보여주세요. 실제 돈을 거래하지 않는 사람을 보여드리겠습니다. 무역은 다른 직업과 마찬가지로 정규직입니다.
이것이 취미라면 왜 이런 종류의 코딩에 시간을 낭비하는지 모르겠습니다. 기술적으로 매우 쉽고 일반적인 개발 작업에서만큼 많은 돈을 벌지 못할 것입니다. 저는 4개의 언어를 사용하는 2백만 라인에 가까운 코드가 있고 메인프레임, PC, UNIX 및 대부분의 Linux 운영 체제의 모든 버전에서 실행되는 일상 업무의 시스템에서 작업합니다.
제 겸손한 의견으로는 기사가 흥미로웠습니다. 그렇다고 해서 그 안에 있는 모든 단어를 믿는 것은 아닙니다. 작성자의 의견일 뿐입니다. 최적화가 함정이라는 결론에 도달하기 위해 많은 최적화를 실행해야 했을 것입니다. 그들이 그렇게했다면 최적화가 작동하지 않기 때문에 기사가 어떻게 정확할 수 있습니까?
@c0d3: 다음은 이 포럼에서 훌륭한 개발자들이 저에게 준 조언입니다. 전략 최적화 프로그램을 사용하지 마십시오(미세 조정 제외). 이상적인 개발 프로세스는 다음과 같습니다. 1) 전략이 타당 하다고 생각 합니다. 2) 전략을 코딩하고 테스트합니다. 4) 전략은 수익성 이 나온다. 5) Optimizer 를 사용하여 미세 조정 합니다. 6) 실패한 부분에서 배운다 .
옵티마이저는 1-pip Sl/Tp를 승패의 차이로 만드는 #-cruncher입니다. 변수를 한 번에 하나씩 최적화하거나 모두 함께 최적화하는 것은 차이가 없습니다. IMO . 여기 내가 1 개월되었을 때 의 성배 가 있습니다. 그렇게 쉬웠다면 더 좋은 방법을 찾지 않았을 것입니다.
수년에 걸쳐 수동으로 시스템을 테스트하고 매 실행 후 한 번에 하나의 매개변수를 변경하여 시스템을 조정할 것이라고 생각한다면 최적화 프로그램을 실행하는 것보다 더 미친 짓입니다. 그러나 opt에서 15,000개의 패스를 실행하고 그 패스 중 어느 것도 패자가 아닌 경우 4주 동안 포워드 테스트를 위해 최소한 데모 계정에 들어갈 준비가 된 시스템이 있는 것입니다. BTW 이 시점에서 실제 코딩 버그를 찾을 것입니다.
이것은 백 테스팅에 대한 좋은 점입니다.