중재 - 페이지 19

 
bstone писал (а):
순전히 호기심으로 소스 코드의 효율성을 평가하는 데 사용되는 방법을 묻는 것이 가능합니까?
bstone , 당신은 비밀을 조기에 공개하고 싶지 않습니다. 테스트 방법이 자신에게 적합하고 어느 정도 확신이 있으면 기존 방식으로 시스템을 계속 테스트하십시오.

나는 이것에 대한 기사를 오랫동안 준비했습니다. 이것은 이것에 관한 것입니다. 거래 포럼에 주기적으로 나타나는 기계식 및 반기계식 Grails 의 약 90-95%. 몇 주 전에는 이미 출판될 수도 있겠다는 생각이 들었지만 최근 Rosh 덕분에 예상치 못한 문제를 발견하고 일단 기사를 천천히 하기로 했습니다. 2~3개월 뒤에는 다시 올려서 완결을 내고 싶다(그렇게 생각하고 싶다). 이 "장기 구축"은 전적으로 내 자신의 연구를 기반으로 하므로 기사가 느리게 진행됩니다. 너무 익지 않은 제품을 제공하고 싶지 않습니다. 그러나 지금도 나는 자신 있게 말할 수 있습니다. 기사는 매우 비관적일 것입니다.

음, 거래 시스템에서 신호가 어떻게 생성되는지 실제로 보려면 소스 코드가 필요합니다. 당연히, 당신은 이것을 블랙박스에서 볼 수 없을 것입니다. 그리고 아니요, 가장 낙관적인 블랙박스 테스트 결과라도 소스 코드를 연구하는 것 이상으로 시스템의 품질에 대해 확신을 줄 것입니다.
 
Mathemat :
나는 여전히 이 고문이 대성공을 거둔 이유가 무엇인지 이해할 수 없었다.
"미친" 성공의 이유는 인형에게 특정 희망을 심어주기 때문입니다.
나는 "중재-비중재" 토론에 참여할 만큼 충분히 유능하지 않으며 자신이 없습니다.
또 다른 성배가 발견되었다는 것을 전문가들에게 증명하기 위해.
나는 첫 번째 버전이 어떻게 죽을지 계속 테스트하고 있습니다.
동시에 입력 필터를 구부러진 핸들로 코드에 나사로 고정하고 데모에서도 테스트합니다.
예를 들어, 4월 17일의 7번 옵션은 보증금을 $2586로 인상했으며, 현재 오픈 포지션 의 이익은 $210입니다(현재 가치는 +1200에 도달했습니다).
예를 들어 수정된 Expert Advisor를 올바르게 테스트하는 방법이 명확하지 않기 때문에 친애하는 Mathemat에게 큰 희망을 둡니다.
데모 결과가 좋으며 오랫동안 떨어질 때까지 기다릴 수 있습니다. 실제 돈에 베팅하는 것은 무섭고 버리기에는 유감입니다.
결정을 내리기 위해서는 테스트 방법론이 필요합니다.
 
Mathemat :

나는 이것에 대한 기사를 오랫동안 준비했습니다. 이것은 이것에 관한 것입니다. 거래 포럼에 주기적으로 나타나는 기계식 및 반기계식 Grails 의 약 90-95%.
글쎄요, 꽤 야심차게 들립니다. 기다릴 것이다.

수학 :

음, 거래 시스템에서 신호가 어떻게 생성되는지 실제로 보려면 소스 코드가 필요합니다. 당연히, 당신은 이것을 블랙박스에서 볼 수 없을 것입니다. 그리고 아니요, 가장 낙관적인 블랙박스 테스트 결과라도 소스 코드를 연구하는 것 이상으로 시스템의 품질에 대해 확신을 줄 것입니다.
그리고 여기에서는 완전히 이해할 수 없습니다. TS가 "신호"를 생성하기 위해 매우 정교한 메커니즘, 예를 들어 MQL4의 60Kb 이상의 소스 코드를 사용한다고 가정해 보겠습니다. 이 코드를 분석한 후 시스템의 일관성과 안정성에 대한 결론을 도출할 수 있다는 것을 올바르게 이해했습니까? 그런데도 테스트할 필요가 없습니까?
 
granit77 :
예를 들어 수정된 Expert Advisor를 올바르게 테스트하는 방법이 명확하지 않기 때문에 친애하는 Mathemat에게 큰 희망을 둡니다.
희망을 주셔서 감사합니다. 나에게도 모든 것이 명확하지 않으며, 나도 어둠 속에서 움직이고 있습니다. 내 의견: 테스터와 MT 옵티마이저 모두 전략의 품질에 대해 확신을 갖고 긍정적인 결정을 내리기에 분명히 충분하지 않습니다.
 
Mathemat :

maksaa는 다음과 같이 썼습니다. 그리고 거래에서 "복잡한" 지표와 고문을 사용할 필요성도 의심하고 싶습니다. 정말 필요한가요? 공식의 복잡성 뒤에 치명적인 오류가 발생하지 않을 확률은 얼마입니까?

"단순한" 정말 안정적이고 수익성 있는 시스템의 예를 보여주세요. 그러면 저도 동의할 것입니다. 그러나 나는 백테스팅과 최적화의 결과와 같은 안정성의 "증거"에 대해 매우 회의적입니다. 내가 기꺼이 고려할 수 있는 유일한 방법은 오픈 소스입니다. 300명의 조언자를 주문하도록 작성한 komposter a 또는 이 태양 아래 있는 모든 것을 실험한 것처럼 보이는 Rosh 에게 물어보십시오. 원래 악기는 "단순"할 수 있지만 해석(즉, 신호)은 그럴 수 없습니다.
나는 훌륭한 전문가가 아니므로 의심 만 표명했습니다. 임호. MTS를 의미하지 않았습니다.
Barishpolet SC는 안정적인 시스템이라고 생각합니다. 아마 들어보셨을 겁니다. 그리고 Reshetov 시스템은 모든 사람들이 스스로 생각했을 때 안정적일 것이라고 생각합니다.

기사를 작성할 때 여기에 신고해 주세요.
 
bstone :
이 코드를 분석한 후 시스템의 일관성과 안정성에 대한 결론을 도출할 수 있다는 것을 올바르게 이해했습니까? 그런데도 테스트할 필요가 없습니까?
설마. 나는 그 기사가 매우 비관적일 것이라고 말했습니다. 그 기사의 주요 결론은 부정적 일 것입니다. 코드를 분석한 후에는 시스템 이 안정적이지 않다는 것을 분명히 선언할 수 있을 뿐입니다. 아아, 비열함의 법칙... 그런 결론이 나면 MT에 대한 테스트가 더 이상 필요하지 않습니다(공식적으로 테스터가 매우 좋은 결과를 보여줄 수 있지만). 그리고 이 정보가 쓸모없다고 말하지 마세요...

나는 명확하고 포괄적인 지속 가능성 기준이 없습니다. 안정성에 필요한 조건에 대한 몇 가지 가설만 있습니다("시스템이 안정적이면 이러한 속성이 있습니다"). 그러나 그들 중 어느 것도 충분하지 않습니다("시스템에 이러한 속성이 있으면 시스템은 안정적입니다").
 
To Mathemat 그리고 Reshetov의 고문을 검사하려면 어떤 코드가 필요합니까? 유리는 모든 것을 제공했습니다. 귀하가 개발한 기준을 고려하면 귀하의 의견이 흥미로울 것입니다.
사실 테스터의 문제는 정말 심각합니다. 이제 작은 따옴표 데이터베이스를 가져오고 Builder에서 이벤트 개발의 객관적인 그림을 보기 위해 Reshetov의 코드를 다시 작성한다고 가정해 보겠습니다. 글쎄, 그럼 나는 나 자신을 위해 그의 아이디어를 현대화할 것입니다. 하지만 시시각각 사건 전개를 살펴봐도 여전히 많은 정보를 놓치고 있다는 것을 알 수 있습니다. 그리고 테스트 결과는 추정 및 예비일 뿐입니다.
일반적으로 실제로 귀하의 기사는 흥미로울 것입니다.

감사합니다. Fed
 
예, Fed , 당신은 나에게 문제를 주었다. 나는 아직 멀티 화폐에 대해 생각조차하지 않았습니다. 아이디어 주셔서 감사합니다.

주어진 한 쌍에서만 작업할 때 불안정하다는 사실은 저자가 직접 게시한 테스트 결과 에서 분명합니다. 그러나 이것이 반드시 불안정한 시스템의 일부 조합이 안정되지 않을 것이라는 의미는 아닙니다.

PS 어, 유리야, 스타일이 있구나. 거대한 start()를 논리적으로 닫힌 여러 개의 작은 블록으로 나누는 것이 정말 어려웠습니까? 같은, 젠장, 172 라인 ...

PPS Yuri, 갑자기 내 기사에 Expert Advisor의 분석을 포함해도 될까요? 이 분석이 확실히 기사에 포함될 것이라고 보장하지는 않지만 그러한 가능성은 존재합니다. 당신을 향한 욕은 없을 것입니다. 걱정하지 마세요. 하지만 분석이 어드바이저로 판단되면 저를 탓하지 마세요... 포럼에서 답변을 하기 싫으시다면 프로필에 제 우편주소로 적어주시면 됩니다.
 

사실 아직도 기사 공개가 늦어질 수 있다는 점에 진심으로 속상했다. 다중 통화 테스트 없이 파트 1을 먼저 출시하고 다음 버전을 출시하는 것이 좋습니다. 솔직히 말해서, 이 주제에 대해 읽고 쓸 줄 아는 무리가 충분하지 않습니다. 개인적으로 테스터를 개발할 때 나는 변덕스럽게 움직입니다. 즉, 위성 위치 데이터를 포함하여 데이터베이스를 프로그래밍하고 작업한 경험이 있습니다. 따옴표는 더 나쁘다. 자료는 다음과 같습니다: 나는 주요 통화 쌍, 분 시세 업데이트 구멍, 계산에 의해 십자가를 얻습니다(십자가의 초기 시세에 15분 동안 구멍이 있음), 종가는 분입니다. 나는 Ask를 Close+spred로, Bid를 그 반대로 모방합니다. 자, 여기에 매복과 오류가 있습니다.

OrderCloseBy 와 같은 mql 명령은 자체 기능으로 다시 작성해야 합니다. 유리가 인디케이터가 없고 코드가 심플해서 좋다. 그리고 내가 전문적으로 테스트에 참여했다면 mql 명령을 dll로 전송할 가치가 있을 것입니다.

유리의 코드는 단순하지만 원시적인 것과는 거리가 멀다. 한편으로는 모든 것이 명확해 보이지만 다른 한편으로 모든 것이 그룹에서 어떻게 작동하는지 파악하는 것은 내 눈에 조금 나쁩니다. 나는 계산된 모든 변수(매분)를 로그 테이블로 전송하고 내 눈으로 이러한 배열을 봅니다. 내부에서 무슨 일이 일어나고 있는지 확인합니다. 그러나 지금까지 나는 그의 코드를 끝까지 전송하는 것을 끝내지 않았습니다. 물론 완전히 이해하게 되면 로그를 읽기 쉬운 상태로 줄이겠습니다. 그 사이 어딘가에서 실수할까 봐 두렵다. 통화 쌍 그룹의 최적 구성을 선택하는 것이 중요합니다. 그런 다음 빌더에서 직접 개선한 다음 축적된 결과를 mql로 전송합니다. 그러나 나는 ... .. 등을 보장하지 않는 과거 데이터를 기반으로 실제 결정(코드를 개선하고 그룹 구성을 평가하기 위해)을 내릴 것입니다. 자, 어떻게 할까요? 또 다른 단점은 다중 통화를 계산하는 데 오랜 시간이 걸린다는 것입니다(이전에 다른 시스템을 시도했습니다). 60분 - 1분이 계산됩니다(+ 데이터도 때때로 계산을 위해 업로드되므로 모든 것이 더 빠르게 움직이고 약 1분 정도 더 걸립니다). 수행된 작업 수(및 테이블의 항목)에 대해 길지 않은 것처럼 보이지만 며칠을 계산할 때는 밤에 설정해야 합니다. 나는 SQL을 잘 알고 있으며 모든 것이 계산에서 최적으로 수행되는 것 같습니다. 그러나 테스트를 위해 1년을 계속 실행하려면 인내심이 없기 때문에 10-20인분을 날립니다.

이제 테스트에 실제로 작동 시간이 있다면 적용하겠습니다. 어쩌면 나는 무언가를 자르거나, 무언가에 더 주의를 기울이거나, 모든 것을 다르게 했을 것입니다.

그래서: 우리는 기사를 기다리고 있습니다!

그리고 Mr. Reshetov의 코드는 정말 흥미롭습니다. 아마도 내 인생에서 많이 보지 못했지만 접근 방식은 정말 혁신적이고 이례적입니다. 내 테스트가 실생활에서 이 도구가 위험을 감수할 가치가 없다는 것을 보여주더라도 나는 여전히 유리에게 매우 감사합니다. 그는 다른 많은 생각을 하게 만듭니다.

감사합니다. Fed

 
Mathemat :
Yuriy, 갑자기 내 기사에 Expert Advisor의 분석을 포함해도 될까요?
이를 위해 소스 코드를 배치하고, 탐구하고, 분석합니다. 그리고 바로 이 분석을 바탕으로 개선하고 염두에 두었습니다. Expert Advisor는 전략에 따라 가장 필요한 성과 기반만을 담고 있습니다.
사유: