도움이 필요하다! 숙제가 풀리지 않아 철의 한계에 부딪혀 - 페이지 14

 
komposter :

...

유사한 트랜잭션 시퀀스가 많이 있으며 각 시퀀스는 시간별로 정렬됩니다.

하나의 시퀀스가 메모리에 들어갈까요?

당신은 전문가를 작성할 수 있습니다. Expert Advisor는 시작할 때 시퀀스 번호(속성 창의 매개변수)를 로드하고 이 시퀀스에 따라 거래합니다. 최적화

작업이 완전히 명확하지 않지만 많은 다른 것들을 상상할 수 있습니다.

 
Integer :

하나의 시퀀스가 메모리에 맞습니까?

당신은 전문가를 작성할 수 있습니다. Expert Advisor는 시작할 때 시퀀스 번호(속성 창의 매개변수)를 로드하고 이 시퀀스에 따라 거래합니다. 최적화

작업이 완전히 명확하지 않지만 많은 다른 것들을 상상할 수 있습니다.

볼륨이 20GB(21 474 836 480바이트)이고 100만 개의 시퀀스가 있는 경우 평균 하나의 시퀀스(~ 21KB)에 대해 약 21 475바이트를 얻게 됩니다. 폰에서도 메모리에 맞아야 한다고 생각함))

A. 그런데 분산 컴퓨팅은 어떻습니까? 나도 그런 생각을 했어야 했는데...

 
그러나 나는 그가 신호에서 기록 파일을 수집했다고 생각합니다)
 

일시 중지에 대해 다시 한 번 죄송합니다. RAM 디스크로 실험했습니다(지금까지는 그다지 성공적이지 않음). 나는 모두 순서대로 대답한다.

Candid :

그러나 시퀀스는 서로 독립적입니까? 그렇다면 한 번 로드된 시퀀스의 날짜에 대해 한 번에 주기를 만드는 것이 불가능한 이유는 무엇입니까? 그런데 여기에서는 효과적인 순환 알고리즘으로 전환하는 것이 가능할 수도 있지만 이것은 운이 좋은 것입니다. 백만 x 백만 차원이 유지되고 파일을 한 번 읽습니다.

물론 일반적으로 다음 반복에서 단계 수가 동일하게 유지되는(즉, 계산이 진행됨에 따라 검색 영역이 좁아지지 않는) 문제는 특별히 강건해 보이지 않습니다. 그러나 이것은 물론 주관적입니다.

독립적 인. 그리고 메모리에 로드하지 않고 한 번에 모든 시퀀스를 통해 루프에 들어가는 방법은 무엇입니까?

올바른 위치에서 시퀀스를 읽는 방법을 알아내면 단계 수를 줄일 수 있습니다(마지막 X는 현재 분석된 날짜부터 처리).

우크라이나 :
전체 데이터베이스가 10줄에 맞습니까? 모든 파일을 함께

100만 시퀀스당 1개의 파일(편의를 위해 각각 9줄로 작성).

글쎄, 또는 백만 개의 파일, 그것은 중요하지 않습니다.

알시믹스 :

다음을 올바르게 이해했습니까?

1) 20GB 파일은 시간순으로 정렬된 약 백만 개의 시퀀스로 구성됩니다.

2) 각 시퀀스의 크기는 다를 수 있으며 시퀀스에 포함 된 트랜잭션 수에 따라 다릅니다.

3) 평균적으로 시퀀스의 크기는 20/10^6 = 20Mb입니다. 하나의 시퀀스를 완전히 다운로드한다고 보장할 수 있습니까?

4) 계수 K는 주어진 시퀀스 내의 트랜잭션에만 의존합니다.

5) 각 시퀀스에 대해 K(10^6개의 총점)를 찾고 상위 10개를 선택해야 합니다.

  1. 20Kb, 우리는 보장할 수 있습니다
  2. 예, 고정 설정이 있는 하나의 기준이 실행당 사용됩니다. 그러나 앞으로는 다음 실행(변경된 기준 또는 기타 설정 포함)도 빨리 고려되기를 바랍니다.
    그러한 볼륨이 있을 때까지 나는 모든 것을 메모리에 로드하고 루프에서 구동하여 필요한 모든 것을 계산했습니다.
  3. 기준 값은 거래 번호 X부터 시작하여 시퀀스의 각 거래에 대해 계산됩니다(계산에 필요한 금액).
    가장 좋은 순서는 우리가 분류하는 히스토리의 각 지점에서 선택해야 합니다(가장 좋은 것은 현재 순간에 가장 좋은 기준이 있는 순서이고 기준은 마지막으로 마감된 거래에 의해 계산됩니다.

알시믹스 :

그리고 시퀀스 사이의 거리 값으로 다른 파일을 생성하면.

나는 이것과 다음을 이해하지 못했다.

솔직한 :
그건 그렇고, 예, 시퀀스 팩을 즉시 다운로드할 수 있습니다.

그것은 저장하지 않을 것입니다, 모두가 필요합니다.

침묵 :

어딘지 모르겠어

Date1에서 Date2 사이의 모든 기준이 있습니다.

즉, 다음을 읽습니다.

파일을 Date1에서 Date2 까지 여러 간격으로 분할하지 않는 이유는 무엇입니까? 닫을 수 있는 작업 시퀀스가 있습니까?

"Date1 - Date2" 간격은 현재 모든 시퀀스의 모든 거래를 포함합니다.

그리고 그것을 여러 개의 작은 것으로 나누는 아이디어는 꽤 건전합니다. 사실, 매개 변수가 변경 될 때마다 디스크에서 정보를 읽어야합니다 .. 그러나 이것은 이미 무언가입니다.

솔직한 :
분명히 단일 날짜 전달의 결과 중 하나는 새 날짜입니다.

네, 하지만 어떤 순서로든 거래가 발생하지 않는 지점을 찾아 휴식을 취하실 수 있을 거라 생각합니다.

그런 다음 다음 간격으로 전환됩니다. 노력하겠습니다.

 
ALXIMIKS :

작업이 다음과 같은 경우:

주어진 행 1 2 3 4 5 6 7 8 9

예를 들어 너비가 4인 경우 너비 내에서 일부 값(예: 최소값)을 찾으려면 전체 행을 따라 이 너비로 이동해야 합니다.

먼저 1 2 3 4 다음 2 3 4 5 다음 3 4 5 6 다음 4 5 6 7 그 다음 .... 등을 찾아야 합니다.

X(거래 수)가 고정되어 있고(귀하의 예에서는 4개) 다른 매개변수가 없는 경우 - 예. 그래서 - 아닙니다.

비닌 :
나는 이 문제에 대해 생각할 것이다.

조건은 위에 설명되어 있습니다. 저희 대열에 오신 것을 환영합니다.)

마케터 :
이 작업은 상당히 학문적이며(프로그래머를 고용할 때 질문처럼 보임) 많은 사람들이 그것에 관심을 보였기 때문에 초기 데이터를 설명하는 형식 측면에서 더 엄격하게 공식화하지 않고 모든 사람이 20GB의 테스트 데이터를 생성할 수 있습니다. 그리고 그들의 실질적인 결정을 제시합니까?

괜찮아요.

시작 날짜 및 시간, 시작 가격, SL, TP, 종료 날짜 및 시간, 종가와 같은 모든 속성을 사용하여 무작위 거래 시퀀스(시간순, 1년 동안)를 생성합니다. 1에서 백만까지 시퀀스에 번호를 매깁니다.

작업은 모든 시퀀스의 모든 거래에서 새로운 일련의 거래를 만드는 것입니다. 차례대로(시간이 교차하지 않음) 특정 기준에 따라 선택됩니다.

기준을 시퀀스의 마지막 20개 거래에 대한 평균 이익이라고 합시다.

결과 예:

  1. 시퀀스 #250, 거래 #53, 기준 = 51: 2013.01.31 00:00 - 2013.02.12 12:30 (기준은 거래 #32-52, 즉 53번째가 참여하지 않은 거래를 기반으로 계산됨)
  2. 시퀀스 #1222, 거래 #28, 기준 = 75: 2013.02.13 10:00 - 2013.02.13 02:21
  3. 등등, 연말까지.

:
그래서 이해합니다, 우리는 자체 제작 테스터/옵티마이저에 대해 이야기하고 있습니까?

예, 그런 것입니다.

세르게예프 :

아니요, 다른 것이 있습니다.

일부 중개인/제공자의 거래 기반을 확인하기 위해 얻었습니다. :)

만약 =)

세르게예프 :

나는 단순화 된 방식으로 작업을 반복합니다

아니 이런 식으로. 구체적인 예를 들었는데 최대한 실제 문제에 가깝다고 볼 수 있습니다.

 
elugovoy :

일반적으로 DB. 하지만 데이터 집계 없이는 방법이 없습니다... 시퀀스의 고유한 속성(날짜부터까지), 이익 K의 평균값 및 분산 D를 별도의 테이블에 작성한 다음 가까운 상위 10개 시퀀스를 찾을 수 있습니다. 원하는 기준에. 이러한 필드에 인덱스가 있는 경우 검색에 시간이 오래 걸리지 않습니다(백만 개의 레코드에서도). 또한 필요한 10개의 시퀀스를 수신하면 초기 데이터를 뒤질 수 있지만 더 이상 백만 개의 검색이 아닙니다. 날짜가 제한되어 있습니다.

기준이 정적인 경우...

매개변수가 변경되면?

자기소개서 :

그것은 여전히 미스터리로 남아 있습니다. 무엇을 찾아야합니까? 모든 작업의 결과는 무엇이어야 합니까? 우리가 주문을 시작/닫는 측면에서 결정을 내리는 것에 대해 이야기하고 있다면 그러한 볼륨을 처리하는 데 상당히 많은 시간이 걸릴 것입니다.

예, 그러면 거래가 있을 것입니다. 그러나 재계산은 가장 최근의 데이터에 대해서만 필요하며 전체 기록을 소세지할 필요는 없습니다.

자기소개서 :

또 다른 점입니다. 우리가 거래에 대해 이야기하고 있기 때문에 각 상품에 대해 개별적으로 거래를 선택하는 것이 합리적일까요? EURUSD, USDJPY 등에 맞게 조정된 동일한 유형의 로봇을 작성하십시오.

이것은 하나의 도구입니다 ...

자기소개서 :

이런 식으로 주어진 시퀀스의 거래(또는 로봇 매개변수 집합)에 사용된 전략만 식별하고 시장의 특정 상황에서 이동하는 것이 가능한 것 같습니다.

정확히.

 
Integer :

하나의 시퀀스가 메모리에 들어갈까요?

당신은 전문가를 작성할 수 있습니다. Expert Advisor는 시작할 때 시퀀스 번호(속성 창의 매개변수)를 로드하고 이 시퀀스에 따라 거래합니다. 최적화

잘 맞을 것이다.

그러나 우리가 필요로 하는 결과는 하나(최종)가 아니라 각 시점에서입니다.

원칙적으로는 매개변수로 계수할 일련번호와 날짜를 제공하여 클라우드를 사용할 수 있습니다. 그러나 이것은 파일을 다시 계산하는 것보다 빠르지 않을 것입니다)

자기소개서 :

A. 그런데 분산 컴퓨팅은 어떻습니까? 나도 그런 생각을 했어야 했는데...

병렬로 무엇을 계산합니까? 다른 시퀀스에 대한 기준의 의미는 무엇입니까?

그러나 이를 위해 메모리에 로드해야 합니다. 그리고 그것이 하나의 프로세스(EA, 터미널)에서 왔는지 아니면 여러 프로세스에서 왔는지는 중요하지 않습니다. 4GB - 8(또는 12, 16, 20) 대신 얻을 수 있습니까? 그러나 여전히 결과를 "접착"해야합니다.

 
komposter :

병렬로 무엇을 계산합니까? 다른 시퀀스에 대한 기준 값은?

이론적으로 모든 이야기를 100개의 그룹으로 나누고 각 그룹에 대한 최적의 선택을 개별적으로 계산할 수 있습니다.

그런 다음 각 그룹에 대해 그룹의 최적 집합에 포함된 스토리만 남겨두고 더 적은 이력으로 다음 단계로 진행합니다. 그런 다음 이론적으로 100번 평행합니다.

메모리에서 모든 것이 정상이며 그룹의 크기를 조정할 수 있습니다.

 
TheXpert :

이론적으로 모든 이야기를 100개의 그룹으로 나누고 각 그룹에 대한 최적의 선택을 개별적으로 계산할 수 있습니다.

그런 다음 각 그룹에 대해 그룹의 최적 집합에 포함된 스토리만 남겨두고 더 적은 이력으로 다음 단계로 진행합니다. 그런 다음 이론적으로 100번 병렬합니다.

그리고 메모리에서 모든 것이 정상이며 그룹의 크기를 조정할 수 있습니다.

100개의 부품 중 100개를 병렬로 로드하면 메모리가 충분하지 않습니다 =)

그리고 순차적으로 로드하는 경우(매번 하나의 최상의 옵션을 기억함) 병렬화는 어디에 있습니까? 그리고 당신이 기계에 접근할 때마다 파일을 읽을 것입니다.

까다로운 부분 로딩 메커니즘을 발명하는 것이 가능하다고 생각하지만 발명해야 합니다.

예를 들어, 첫 번째 읽기 동안 시작 날짜 이전에 마지막 거래가 마감된 각 패스를 찾아 X개의 이전 거래를 읽고 이 거래가 끝나는 파일 지점을 기억합니다.

그 후 결과에 포함된 첫 번째 거래를 찾은 다음 새로운 데이터로만 작업합니다. 원하는 지점에서 새로운 현재 날짜로 파일을 읽고 배열의 거래를 이동할 때마다(고정된 배열 크기 를 얻습니다. - X 요소).

이것은 다중 읽기 문제(그냥 필요하지 않음)와 메모리 문제(X백만 거래를 맞출 수 있는 경우에만)를 모두 해결할 것입니다.

이 방향으로 이동하겠습니다.

 

그런데 바이너리 파일로의 전환은 실제로 크기가 증가하지 않았습니다.

내가 최적화한 텍스트 형식은 매우 간결했습니다. 패스당 하나의 날짜(첫 거래 시작)가 기억되고 나머지(개시 및 종가 모두)는 이전 날짜의 오프셋으로 기억됩니다. SL, TP 및 종가도 시가에서 오프셋으로 저장되었습니다.

그리고 이진 형식으로 전환할 때 이 최적화는 더 이상 의미가 없습니다. 초 단위 오프셋(단위: 단위)은 본격적인 날짜만큼 많은 공간을 차지합니다(저는 오래 거부했습니다. 저는 2030년이면 충분합니다). ushort는 이미 그렇지 않습니다. 충분합니다(최대 오프셋 18시간). 가격과 유사하게 - 오프셋은 ushort로 변환될 수 있지만 오버플로에 대한 검사를 추가해야 하며(예: SL = 0인 경우) 이득은 3가지 가격 모두에서 6바이트에 불과합니다. 하지 않기로 결정했습니다.

그러나 나는 약간의 추가 정보를 제거했고 결과적으로 여전히 20%를 얻었습니다. 원본 파일의 예상 크기(20GB)는 7-8GB이며 몇 시간 안에 변환됩니다.

글쎄, 문자열을 변환 하는 프로세서 시간이 이겼습니다.