그것은 0.8 일 범위의 손실 후 - 6 거래 후, 우리가 새로운 고점을 너무 오래 기다리기 때문에 거래에서 철수해야 함을 의미합니다.
그게 다야
예제 643642를 고려해 보겠습니다. 최적화 동안에는 큰 손실이 없었습니다(범위의 0.6보다 큰 손실은 없었음).
거래 중에 0.6 이상의 손실이 쉽게 발생할 수 있습니다 (실제 틱에서 볼 수 있음). 범위의 0.6 이상 손실의 경우 TS에서 다시 이길 기회를 박탈하는 것으로 나타났습니다. 그리고 이것은 논리적이지 않으며 실제 틱에서 다시 볼 수 있습니다. 이 손실은 시스템이 작동을 멈춘다는 의미가 아니라 OHLC에서 모델링되지 않았을 뿐입니다. TS가 상당한 손실을 입는 즉시 최대값을 업데이트하지 않아 자동으로 경매에서 철회되는 것으로 나타났습니다.
임호. 어떻게든 차량의 짓밟힘을 한 곳에서 분리하고 손실 후 복구가 필요합니다. 예를 들어 n-trade에 대한 평균 수익성 기준을 도입합니다.
실제 틱에 대한 최적화 후 확인이 TS 동작의 숨겨진 측면을 이해하는 데 유용할 수 있다는 점에 여전히 동의하지 않습니까?
예제 643642를 고려해 보겠습니다. 최적화 동안에는 큰 손실이 없었습니다(범위의 0.6보다 큰 손실은 없었습니다).
거래 중에 0.6 이상의 손실이 쉽게 발생할 수 있습니다 (실제 틱에서 볼 수 있음). 범위의 0.6 이상 손실의 경우 TS에서 다시 이길 기회를 박탈하는 것으로 나타났습니다. 그리고 이것은 논리적이지 않으며 실제 틱에서 다시 볼 수 있습니다. 이 손실은 시스템이 작동을 멈춘다는 의미가 아니라 OHLC에서 모델링되지 않았을 뿐입니다. TS가 상당한 손실을 입는 즉시 최대값을 업데이트하지 않아 자동으로 경매에서 철회되는 것으로 나타났습니다.
시스템이 거래에서 제거되어야 하는 것은 모델링되지 않았기 때문입니다.
거래에서 철수하는 이유의 본질은 시스템이 역사에서와 다르게 작동한다는 것입니다. 그리고 왜 이런 일이 발생했는지는 중요하지 않습니다. 테스트 중에 무언가를 고려하지 않았거나, 시장이 변경되었거나, 알고리즘 자체에서 실수가 발생했습니다.
거래에서 시스템을 철수하게 한 손실이 우발적 인 경우 하루 안에 시스템이 다시 최적화되고 다시 최적화 결과가 실제 거래의 결과보다 확실히 좋으며 즉시 시작됩니다 이전과 같은 결과를 보여줍니다. 더군다나 사단은 역할을 하지 않고 보고서용 통계를 수집하는 스크립트는 모든 사업부에 대해 한 번에 수집하지만 물론 상위 사단의 차량만 상위에 오르기 때문에 보고서에 대한 통계를 수집하는 스크립트는 중간 또는 하위 디비전은 상위 디비전의 고품질 거래를 보여주기 시작합니다. 즉시 상위 디비전으로 이전됩니다.
즉, Eduard가이 TS가 당신에게 너무 소중하다면 최대 손실은 10 거래입니다. 이것이 "6"이라는 점을 감안할 때 그녀의 각 거래는 매우 작습니다. 암튼 재최적화 후 바로 탑디비전 진입시 관심있는 분들에게 잊지않고 알려드리도록 노력하겠습니다.
임호. 어떻게든 차량의 짓밟힘을 한 곳에서 분리하고 손실 후 복구가 필요합니다. 예를 들어 n-trade에 대한 평균 수익성 기준을 도입합니다.
그는 분열되어 있지 않습니까?
이봐, 우리는 2년 동안 시스템이 어떻게 작동하는지 확인했어. 그리고 우리는 가장 긴 회복 기간을 가지고 있습니다. 실제 거래의 TS가 복구하는 데 더 오랜 시간이 걸린다면 이는 TS가 의도한 대로 작동하지 않는다는 명백한 신호입니다(반복하지만, 이 이유는 우리에게 중요하지 않습니다).
왜 허용되지 않습니까? TP 후행이 그러한 조건에서 가격을 정확하게 "따라잡을" 것으로 판명되면 0.8 일일 범위의 손실로 거래를 마감하는 것을 정확히 허용하지 않는 기능은 무엇입니까?
나는 예약했다.
그것은 0.8 일 범위의 손실 후 - 6 거래 후, 우리가 새로운 고점을 너무 오래 기다리기 때문에 거래에서 철수해야 함을 의미합니다.
힘드세요... :-)
같은 곳에서 잡담 후, Equity 이상으로 비행이 가능합니다!!!!?!?!
병합 스타터가 사라지면 - 예. 물론 - 당신이 더 잘 알고 있지만 ... 우리는 더 관찰합니다 ...
사용 가능.
그러나 2년 연속으로 그렇지 못했다. 그리고 우리는 "출발 정상"을 기다릴 것입니다 ??? 물론 가능하지만 내 생각에는 "하향"의 가능성이 더 큽니다.
나는 예약했다.
그것은 0.8 일 범위의 손실 후 - 6 거래 후, 우리가 새로운 고점을 너무 오래 기다리기 때문에 거래에서 철수해야 함을 의미합니다.
그게 다야
예제 643642를 고려해 보겠습니다. 최적화 동안에는 큰 손실이 없었습니다(범위의 0.6보다 큰 손실은 없었음).
거래 중에 0.6 이상의 손실이 쉽게 발생할 수 있습니다 (실제 틱에서 볼 수 있음). 범위의 0.6 이상 손실의 경우 TS에서 다시 이길 기회를 박탈하는 것으로 나타났습니다. 그리고 이것은 논리적이지 않으며 실제 틱에서 다시 볼 수 있습니다. 이 손실은 시스템이 작동을 멈춘다는 의미가 아니라 OHLC에서 모델링되지 않았을 뿐입니다. TS가 상당한 손실을 입는 즉시 최대값을 업데이트하지 않아 자동으로 경매에서 철회되는 것으로 나타났습니다.
임호. 어떻게든 차량의 짓밟힘을 한 곳에서 분리하고 손실 후 복구가 필요합니다. 예를 들어 n-trade에 대한 평균 수익성 기준을 도입합니다.
실제 틱에 대한 최적화 후 확인이 TS 동작의 숨겨진 측면을 이해하는 데 유용할 수 있다는 점에 여전히 동의하지 않습니까?
그게 다야
예제 643642를 고려해 보겠습니다. 최적화 동안에는 큰 손실이 없었습니다(범위의 0.6보다 큰 손실은 없었습니다).
거래 중에 0.6 이상의 손실이 쉽게 발생할 수 있습니다 (실제 틱에서 볼 수 있음). 범위의 0.6 이상 손실의 경우 TS에서 다시 이길 기회를 박탈하는 것으로 나타났습니다. 그리고 이것은 논리적이지 않으며 실제 틱에서 다시 볼 수 있습니다. 이 손실은 시스템이 작동을 멈춘다는 의미가 아니라 OHLC에서 모델링되지 않았을 뿐입니다. TS가 상당한 손실을 입는 즉시 최대값을 업데이트하지 않아 자동으로 경매에서 철회되는 것으로 나타났습니다.
시스템이 거래에서 제거되어야 하는 것은 모델링되지 않았기 때문입니다.
거래에서 철수하는 이유의 본질은 시스템이 역사에서와 다르게 작동한다는 것입니다. 그리고 왜 이런 일이 발생했는지는 중요하지 않습니다. 테스트 중에 무언가를 고려하지 않았거나, 시장이 변경되었거나, 알고리즘 자체에서 실수가 발생했습니다.
거래에서 시스템을 철수하게 한 손실이 우발적 인 경우 하루 안에 시스템이 다시 최적화되고 다시 최적화 결과가 실제 거래의 결과보다 확실히 좋으며 즉시 시작됩니다 이전과 같은 결과를 보여줍니다. 더군다나 사단은 역할을 하지 않고 보고서용 통계를 수집하는 스크립트는 모든 사업부에 대해 한 번에 수집하지만 물론 상위 사단의 차량만 상위에 오르기 때문에 보고서에 대한 통계를 수집하는 스크립트는 중간 또는 하위 디비전은 상위 디비전의 고품질 거래를 보여주기 시작합니다. 즉시 상위 디비전으로 이전됩니다.
즉, Eduard가이 TS가 당신에게 너무 소중하다면 최대 손실은 10 거래입니다. 이것이 "6"이라는 점을 감안할 때 그녀의 각 거래는 매우 작습니다. 암튼 재최적화 후 바로 탑디비전 진입시 관심있는 분들에게 잊지않고 알려드리도록 노력하겠습니다.
현재 탑 디비전에서는 90대의 차량이 거래되고 있습니다.
임호. 어떻게든 차량의 짓밟힘을 한 곳에서 분리하고 손실 후 복구가 필요합니다. 예를 들어 n-trade에 대한 평균 수익성 기준을 도입합니다.
그는 분열되어 있지 않습니까?
이봐, 우리는 2년 동안 시스템이 어떻게 작동하는지 확인했어. 그리고 우리는 가장 긴 회복 기간을 가지고 있습니다. 실제 거래의 TS가 복구하는 데 더 오랜 시간이 걸린다면 이는 TS가 의도한 대로 작동하지 않는다는 명백한 신호입니다(반복하지만, 이 이유는 우리에게 중요하지 않습니다).
실제 틱에 대한 최적화 후 확인이 TS 동작의 숨겨진 측면을 이해하는 데 유용할 수 있다는 점에 여전히 동의하지 않습니까?
나는 그것의 요점을 이해하지 못한다. 예전부터 다시는 없을 것입니다.
그러나 아무도 당신이 직접 하는 것을 막지 않습니다. 제한이 없는 모든 차량은 등록 코드 없이 테스터에서 작동합니다.
로그는 이 코드에 대해 무엇을 말합니까? 유효하지 않은???
나는 확인했고 모든 것이 작동하는 것 같습니다 ...
나는 그 문제가 regcode에 없다고 제안하고 싶습니다.여기에 내가 넣어
여기 날아
reg 코드에 맹세
계정: 2599118
마법: 542041
등록 코드: 3265001878
놓다
진드기의 출현으로 날아 갔다 ...
여기 로그가 있습니다
로만, 그녀는 마법을 걸고 맹세합니다. 542041의 빌드 날짜는 2019년 6월 12일입니다. 실행 가능한 모듈은 6월입니다. 내 생각에 이 실행 파일이 생성되었을 때 542041은 아직 존재하지 않았습니다.
최신 모듈을 사용하면 작동합니다.
나는 그것의 요점을 이해하지 못한다. 예전부터 다시는 없을 것입니다.
그렇다면 히스토리를 최적화하는 요점은 무엇입니까?
기술적으로 가능하다면(시간 비용 측면에서), 나는 일반적으로 실제 틱에서만 모든 것을 최적화할 것입니다.