오리는 저장하지 않습니다-모든 것이 이미 아무데도 단순화되지 않았습니다. 중요한 것은 수수료를 계산하는 것을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 어깨에서 WF를 잘라냅니다.
오리 도움이되지 않습니다-모든 것이 이미 아무데도 단순화되지 않았으며 가장 중요한 것은 수수료 계산을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 어깨에서 WF를 잘라냅니다.
140,000,000??? 당신은 건초 더미에서 바늘을 찾고 있습니다. 특정 항목으로 검색 범위를 좁혀야 합니다.
오리는 저장하지 않습니다-모든 것이 이미 아무데도 단순화되지 않았습니다. 중요한 것은 수수료를 계산하는 것을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 WF를 어깨에서 잘라냅니다.
그 많은 전략을 어디서 얻었습니까? 당신은 몇 달 동안 하나를 만지작거리고 있었습니다... 당신은 어떤 것을 살지 선택하기 위해 시장에서 다른 사람들의 Expert Advisors를 테스트합니까?
Igor Volodin : WF의 아이디어는 간단합니다. 입구에서 쓰레기를 제공하고 사탕을 얻는 또 다른 아이디어가 있습니다.
그리고 왜 쓰레기가 무엇이고 사탕이 무엇인지 기계보다 더 잘 이해하기로 결정했습니다. 그렇다면 왜 컴퓨터를 믿으십니까? 아마도 모두 손으로.
전략에 1-2개의 매개변수만 있으면 이미 사전 정의되어 있으며 원칙적으로 그러한 결정에 적합하지 않습니다. 이론적으로 여기에서 WF의 전체 아이디어는 전략이 미리 정의되지 않은 경우(특정 상황에 맞게 설계되지 않은 경우) WF가 수익성 있는 집합을 선택한 다음 확인하고 모든 것이 정상이면 이 이미 성공하고 다른 시간 단계에서 다시 시작합니다(전략이 미리 결정된 경우 모든 패스의 70%가 거기에서 수익성이 있다는 것이 논리적입니다. 그렇다면 WF가 필요한 이유는 무엇입니까?)
논쟁하고 싶지도 않습니다. 그러나 단일 연구(단일 값)에 대해 WF를 수행하는 것은 죽은 비즈니스 IMHO입니다.)
모든 테스트 방법은 투자한 금액을 정확하게 제공하며 그 이상도 그 이하도 아니며 다른 많은 방법을 구현할 수는 없지만 모든 것이 항상 그렇습니다.
오히려 저는 이 입장에 동의합니다. 나는 "분산" 테스팅을 시도했는데, 다른 코드 변형에 대해 "책임 있는"을 선택했을 때 마치 시간을 절약하고 앞으로 비교하여 전체 결과에 눈을 돌리는 것처럼 변수만 최적화했습니다. 그러나 아무 일도 일어나지 않았다. 분명히 좋은 시스템에서 그 부분은 상호 의존적이며 하나의 불균형은 전체 시스템의 실패로 이어집니다.
(그래서 그건 그렇고, 변수가 적은 작동 시스템은 없습니다. 마치 비행기와 같습니다. 적어도 하나의 기능이 비행 조건에 적응하지 않으면 조만간 떨어질 것입니다. 그리고 그 기능은 외견상 단순하지만 , 이착륙하는 비행기가 복잡할수록 고려하는 요소가 많을수록 더 안정적입니다.)
반면에 일부 변수는 시스템의 장기 "메모리"에 대한 책임이 있고 다른 변수는 운영에 대한 책임이 있음이 분명합니다. 따라서 앞으로 최적화 기간이 다른 그룹으로 나누는 방법을 이미 알아냈습니다. 그 동안 모든 변수에 대한 지원은 동일합니다. 이것은 잘못된 것입니다. 그러나 앞으로 나아가면 이 문제를 해결할 수 있습니다.
또 다른 질문은 프로세스 속도 를 높이기 위해 많은 것을 희생할 수 있다는 것입니다. 예를 들어,
1. 진드기가없는 사람을 운전하는 것은 의미가 없습니다. WF에서의 테스트는 본질적으로 상대적이며 최상의 옵션을 선택하기 위해 환경 조건에 대한 초정밀 준수가 필요하지 않습니다. 저것들. 좋은 결정이고 아프리카에서는 좋은 결정입니다.
2. 변수는 차례로 최적화될 수 있으며 함께 최적화될 수는 없습니다. 그런 다음 클라우드는 ... 고유한 방식으로 이동하며 에이전트와 다소간 관계를 유지할 수 있습니다. 동시에 최적화 품질도 다르지 않아 확인 했다. 이것은 분명히 Volkin에서 기록의 별도 섹션이 특정 변수에 대해 두 번 이상 최적화되기 때문에 발생합니다. 그리고 이 지점 상황에서 잡히지 않은 변수의 상호 작용은 항상 다음 단계에서 나타날 기회가 있습니다.
3. 프로세스에서 실패한 결정을 포착하고 다음 작업으로 넘어갈 수 있습니다. 창의성의 여지가 있습니다(표준과의 비교, 명백한 마이너스에 대한 반응 등).
WF로 작업할 때 문제는 리소스에 대해서만 발생하며 매우 강력한
여러 섹션(예: 3-6개월)에서 포워드가 형편없다고 판단되면 프로세스를 중단하고 문제를 분석합니다.
좋은 시스템에는 최적화할 매개변수가 거의 없습니다(이상적으로는 1-2개).
그러나 WF를 기반으로 하는 모든 것과 모든 것의 자동 래핑 정렬을 만들고자 한다면 이것은 건설이 아니라 벽돌을 던지는 것입니다.
단순화된 신호 계산 방식의 핵심입니다.
오리는 저장하지 않습니다-모든 것이 이미 아무데도 단순화되지 않았습니다. 중요한 것은 수수료를 계산하는 것을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 어깨에서 WF를 잘라냅니다.
여러 섹션(예: 3-6개월)에서 포워드가 형편없다고 판단되면 프로세스를 중단하고 문제를 분석합니다.
좋은 시스템에는 최적화할 매개변수가 거의 없습니다(이상적으로는 1-2개).
그러나 WF를 기반으로 하는 모든 것과 모든 것의 자동 래핑 정렬을 만들고자 한다면 이것은 건설이 아니라 벽돌을 던지는 것입니다.
저것들. 사이트에서 사전에 수익성 있는 시스템을 사용하고 WF가 나를 위해 수익 수준을 변경하는 방법을 지켜본다면 - 멋진가요? 이것은 새싹의 전체 아이디어를 파괴합니다
WF의 아이디어는 간단합니다. 입구에서 쓰레기를 제공하고 사탕을 얻는 또 다른 아이디어가 있습니다.
오리 도움이되지 않습니다-모든 것이 이미 아무데도 단순화되지 않았으며 가장 중요한 것은 수수료 계산을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 어깨에서 WF를 잘라냅니다.
오리는 저장하지 않습니다-모든 것이 이미 아무데도 단순화되지 않았습니다. 중요한 것은 수수료를 계산하는 것을 잊지 않는 것입니다.) 일반적으로 서로의 성공을 기원하는 것이 옳을 것이라고 생각합니다.
그건 그렇고, 여기 입구에 약 140,000,000개 이상의 주요 "전략"이 있습니다. 각 전략에는 약 50-500개의 패스만 있고 WF는 이 모든 것의 핵심입니다(+ 작은 것들을 위한 많은 장치). 단순히 계산하는 것이 현실적이지 않으며, 각 시스템에 보고서를 저장하는 것조차 이미 문제가 있습니다.
리소스 부족은 단순히 치명적이지만 특정 항목에서 WF를 확인하면 다시 아이디어에 따라 WF를 어깨에서 잘라냅니다.
WF의 아이디어는 간단합니다. 입구에서 쓰레기를 제공하고 사탕을 얻는 또 다른 아이디어가 있습니다.
그리고 왜 쓰레기가 무엇이고 사탕이 무엇인지 기계보다 더 잘 이해하기로 결정했습니다. 그렇다면 왜 컴퓨터를 믿으십니까? 아마도 모두 손으로.
전략에 1-2개의 매개변수만 있으면 이미 사전 정의되어 있으며 원칙적으로 그러한 결정에 적합하지 않습니다. 이론적으로 여기에서 WF의 전체 아이디어는 전략이 미리 정의되지 않은 경우(특정 상황에 맞게 설계되지 않은 경우) WF가 수익성 있는 집합을 선택한 다음 확인하고 모든 것이 정상이면 이 이미 성공하고 다른 시간 단계에서 다시 시작합니다(전략이 미리 결정된 경우 모든 패스의 70%가 거기에서 수익성이 있다는 것이 논리적입니다. 그렇다면 WF가 필요한 이유는 무엇입니까?)
당신이 쓴 모든 것은 문제에 대한 완전한 오해를 보여줍니다.
당신은 새롭고 발명된 방법을 가지고 있습니다
WF에 관한 좋은 문구가 있습니다.
WF 테스트를 통해 합리적인 '자유도'를 유지하면서 거래 시스템을 개발할 수 있습니다.
나는 Urain의 말로 대답할 것이다 당신은 당신이 발명한 새로운 방법을 가지고 있습니다.
논쟁하고 싶지도 않습니다. 그러나 단일 연구(단일 값)에 대해 WF를 수행하는 것은 죽은 비즈니스 IMHO입니다.)
모든 테스트 방법은 투자한 금액을 정확하게 제공하며 그 이상도 그 이하도 아니며 다른 많은 방법을 구현할 수는 없지만 모든 것이 항상 그렇습니다.
논쟁하고 싶지도 않습니다. 그러나 단일 연구(단일 값)에 대해 WF를 수행하는 것은 죽은 비즈니스 IMHO입니다.)
모든 테스트 방법은 투자한 금액을 정확하게 제공하며 그 이상도 그 이하도 아니며 다른 많은 방법을 구현할 수는 없지만 모든 것이 항상 그렇습니다.
오히려 저는 이 입장에 동의합니다. 나는 "분산" 테스팅을 시도했는데, 다른 코드 변형에 대해 "책임 있는"을 선택했을 때 마치 시간을 절약하고 앞으로 비교하여 전체 결과에 눈을 돌리는 것처럼 변수만 최적화했습니다. 그러나 아무 일도 일어나지 않았다. 분명히 좋은 시스템에서 그 부분은 상호 의존적이며 하나의 불균형은 전체 시스템의 실패로 이어집니다.
(그래서 그건 그렇고, 변수가 적은 작동 시스템은 없습니다. 마치 비행기와 같습니다. 적어도 하나의 기능이 비행 조건에 적응하지 않으면 조만간 떨어질 것입니다. 그리고 그 기능은 외견상 단순하지만 , 이착륙하는 비행기가 복잡할수록 고려하는 요소가 많을수록 더 안정적입니다.)
반면에 일부 변수는 시스템의 장기 "메모리"에 대한 책임이 있고 다른 변수는 운영에 대한 책임이 있음이 분명합니다. 따라서 앞으로 최적화 기간이 다른 그룹으로 나누는 방법을 이미 알아냈습니다. 그 동안 모든 변수에 대한 지원은 동일합니다. 이것은 잘못된 것입니다. 그러나 앞으로 나아가면 이 문제를 해결할 수 있습니다.
또 다른 질문은 프로세스 속도 를 높이기 위해 많은 것을 희생할 수 있다는 것입니다. 예를 들어,
1. 진드기가없는 사람을 운전하는 것은 의미가 없습니다. WF에서의 테스트는 본질적으로 상대적이며 최상의 옵션을 선택하기 위해 환경 조건에 대한 초정밀 준수가 필요하지 않습니다. 저것들. 좋은 결정이고 아프리카에서는 좋은 결정입니다.
2. 변수는 차례로 최적화될 수 있으며 함께 최적화될 수는 없습니다. 그런 다음 클라우드는 ... 고유한 방식으로 이동하며 에이전트와 다소간 관계를 유지할 수 있습니다. 동시에 최적화 품질도 다르지 않아 확인 했다. 이것은 분명히 Volkin에서 기록의 별도 섹션이 특정 변수에 대해 두 번 이상 최적화되기 때문에 발생합니다. 그리고 이 지점 상황에서 잡히지 않은 변수의 상호 작용은 항상 다음 단계에서 나타날 기회가 있습니다.
3. 프로세스에서 실패한 결정을 포착하고 다음 작업으로 넘어갈 수 있습니다. 창의성의 여지가 있습니다(표준과의 비교, 명백한 마이너스에 대한 반응 등).