Stanislav Korotky : 간접적으로 비슷한 검사를 했습니다. 첫 번째 트랜잭션은 항상 잔액 보충입니다(모든 실행에서 동일함). 그래서 OnTester에서 첫 거래의 HistoryDealGetInteger(ticket, DEAL_TIME )를 기억하고 프레임에 썼습니다. 이 값으로 OnTesterPass의 전체 실행 세트를 앞뒤로 나눌 수 있습니다. 가능하면 OnTester에서 OnTesterPass로 필요한 계산에 대한 값을 전달하고 OnTesterPass에서 자체 계산을 수행합니다.
실행당 단일 거래 배열을 얻으면 첫 번째 거래를 잡을 수 있습니다. 즉, 잔액의 크기에 의한 백의 보충과 같은 양의 포워드의 두 번째 보충입니다. 포워드 부분까지의 모든 트랜잭션 결과가 동일한 라운드 합계와 같을 확률은 거의 없습니다.
Igor Volodin : 이해했다. 여기서 가로축은 시간의 선형 증분에 해당합니다. 하지만 부과할 문제는 보이지 않습니다. 초기 보증금만 다릅니다. 앞으로의 경우 = 뒤로 기간의 합계입니다. 그러나 우리가 이익 증가 차트를 취하고 기준으로 0을 취하면 한 지점에서 시작됩니다.
나는 초기 보증금을 희생할 수 있다고 생각합니다. 모든 사람들은 이것이 어쨌든 관습이라는 것을 이해합니다. 가장 중요한 것은 모든 포워드가 동일한 시작 보증금을 가져야 한다는 것입니다.
나는 앞으로 걸어가는 패션이 모퉁이를 돌고 있다는 사실을 알고 있는 경향이 있고 우리는 이미 일종의 공통 이미지 표준을 제시해야 합니다.
타임라인이 모든 사람에게 동일하다는 점이 마음에 듭니다. 거래의 상대적 밀도를 즉시 느낄 수 있습니다.
간접적으로 비슷한 검사를 했습니다. 첫 번째 트랜잭션은 항상 잔액 보충입니다(모든 실행에서 동일함). 그래서 OnTester에서 첫 거래의 HistoryDealGetInteger(ticket, DEAL_TIME )를 기억하고 프레임에 썼습니다. 이 값으로 OnTesterPass의 전체 실행 세트를 앞뒤로 나눌 수 있습니다. 가능하면 OnTester에서 OnTesterPass로 필요한 계산에 대한 값을 전달하고 OnTesterPass에서 자체 계산을 수행합니다.
네. 이것은 ini에서 "forward" 옵션의 위치를 추출하고 테스터의 모드(간단한 테스트 또는 최적화)도 확인해야 함을 의미합니다. 함수가 간단한 테스트 중에만 실행되도록 하고 앞으로가 선택되었을 때?
Forward=Custom, Optimization=Disabled, OnTester No. 2(여기에서는 또한 조용히 작업하기 위해 TesterPass로 전송하는 것이 좋습니다) 파일에 회귀와 함께 수익성을 기록합니다.
이 경우에만 OnTester No. 2가 발생하고 포워드를 사용한 최적화의 경우에만 발생한다고 생각합니다. 그러나 나는 그것을 사용하지 않으며,
OnTester №2를 통한 파일 회귀.
둘 사이의 경계 를 프로그래밍 방식으로 정의하는 것은 불가능합니다.
이 스레드를 너무 늦게 알아차렸습니다. 해결책이 있습니다. 최근에는 백 + 포워드 테스트를 위한 시각적 도구로 고민했습니다. 프로그래밍 방식으로 결정하는 것은 불가능하다는 것을 깨달았지만 앞뒤로 실행의 패스 번호는 동일합니다.
따라서 정방향 실행에서 첫 번째 프레임이 도착하는 순간은 저장된 패스 번호 풀에서 쉽게 찾을 수 있습니다.
거래의 IN/OUT 시간도 고정할 수 있습니다. 프로필에 포워드의 순간이 점선으로 고정된 사진이 있는데 사실 이후에 결정
수영장 자체.-)
이 스레드를 너무 늦게 알아차렸습니다. 해결책이 있습니다. 최근에는 백 + 포워드 테스트를 위한 시각적 도구로 고민했습니다. 프로그래밍 방식으로 결정하는 것은 불가능하다는 것을 깨달았지만 앞뒤로 실행의 패스 번호는 동일합니다.
따라서 정방향 실행에서 첫 번째 프레임이 도착하는 순간은 저장된 패스 번호 풀에서 쉽게 찾을 수 있습니다.
거래의 IN/OUT 시간도 고정할 수 있습니다. 프로필에 포워드의 순간이 점선으로 고정된 사진이 있는데 사실 이후에 결정
그들은 결합됩니다. 최적화 프로그램에서 앞으로가 선택되었습니다 = 그래프에서 볼 수 있는 기간의 1/2. 결합된 실행 중 하나가 데이터 그리드에서 선택되고 해당 선이 차트에 표시됩니다.
그들은 결합됩니다. 최적화 프로그램에서 앞으로가 선택되었습니다 = 그래프에서 볼 수 있는 기간의 1/2. 결합된 실행 중 하나가 데이터 그리드에서 선택되고 해당 선이 차트에 표시됩니다.
이것은 초기 보증금에 대한 정렬입니다. 포워드의 초기 보증금을 처리할 수 있습니까?
이해했다. 여기서 가로축은 시간의 선형 증분에 해당합니다. 하지만 부과할 문제는 보이지 않습니다. 초기 보증금만 다릅니다. 앞으로의 경우 = 뒤로 기간의 합계입니다.
그러나 우리가 이익 증가 차트를 취하고 기준으로 0을 취하면 한 지점에서 시작됩니다.
Ps 나 개인적으로 그런 일정의 유용성이 의심 스럽습니다.
이해했다. 여기서 가로축은 시간의 선형 증분에 해당합니다. 하지만 부과할 문제는 보이지 않습니다. 초기 보증금만 다릅니다. 앞으로의 경우 = 뒤로 기간의 합계입니다.
그러나 우리가 이익 증가 차트를 취하고 기준으로 0을 취하면 한 지점에서 시작됩니다.
나는 초기 보증금을 희생할 수 있다고 생각합니다. 모든 사람들은 이것이 어쨌든 관습이라는 것을 이해합니다. 가장 중요한 것은 모든 포워드가 동일한 시작 보증금을 가져야 한다는 것입니다.
나는 앞으로 걸어가는 패션이 모퉁이를 돌고 있다는 사실을 알고 있는 경향이 있고 우리는 이미 일종의 공통 이미지 표준을 제시해야 합니다.
타임라인이 모든 사람에게 동일하다는 점이 마음에 듭니다. 거래의 상대적 밀도를 즉시 느낄 수 있습니다.
이 스레드를 너무 늦게 알아차렸습니다. 해결책이 있습니다. 최근에는 백 + 포워드 테스트를 위한 시각적 도구로 고민했습니다. 프로그래밍 방식으로 결정하는 것은 불가능하다는 것을 깨달았지만 앞뒤로 실행의 패스 번호는 동일합니다.
따라서 정방향 실행에서 첫 번째 프레임이 도착하는 순간은 저장된 패스 번호 풀에서 쉽게 찾을 수 있습니다.
거래의 IN/OUT 시간도 고정할 수 있습니다. 프로필에 포워드의 순간이 점선으로 고정된 사진이 있는데 사실 이후에 결정