자바스크립트와 함께 게임을 하는 노인 - 구매를 하는 파트너를 만드는 5) 로봇 또한 버그

저자:작은 꿈, 창간: 2017-03-13 12:53:50, 업데이트: 2017-10-11 10:37:32

노인과 함께 자바스크립트 게임을 하며 구매를 하는 파트너를 만들 수 있습니다.

JS를 사용하여 양적 로봇을 작성하는 튜토리얼:https://www.fmz.com/bbs-topic/705(마르크 아래로)
  • 1, K 라인의 데이터 기초, 양적 거래에서 데이터를 사용하는 데 발생하는 문제.

    • K 라인 데이터란 무엇인가요?

      K선 차트는 일본의 도카와 막부 시대에서 유래되었으며, 당시 일본 쌀 시장의 상인들이 쌀 시장의 행보와 가격 변동을 기록하기 위해 사용되었으며, 그 후 세밀한 독특한 표기 방식으로 주식 시장과 선물 시장에 도입되었다. 현재 이러한 그래프 분석 방법은 우리나라와 동남아시아 전역에서 특히 인기를 끌고 있습니다. 이 방법으로 그려진 그래프의 모양은 과 비슷하며, 이 에 검은색과 흰색의 음절이 추가되어 있기 때문에 일선 차트라고도 불립니다. K선 차트를 통해 우리는 하루 또는 특정 기간의 시장 상태를 기록 할 수 있습니다. 주가가 잠시 동안 기록된 후, 차트에서 완전히 형성 된 특정 지역 또는 형태는 완전히 다른 형태를 나타냅니다. 우리는 이러한 형태 변화에서 무언가를 감지 할 수있는 법칙을 감지 할 수 있습니다. (바다에서 검색)

      이 그래프는 설명하지 않습니다. JS 언어를 사용하여 정의된 K줄의 데이터 구조를 살펴봅시다.

      {
          Time    :   1487034000000, // 一个时间戳, 精确到毫秒,与Javascript的 new Date().getTime() 得到的结果格式一样
          Open    :   3425,          // 开盘价
          High    :   3446,          // 最高价
          Low     :   3423,          // 最低价
          Close   :   3438,          // 收盘价
          Volume  :   177657.99,     // 交易量
      }
      

      이제 GetRecords 함수를 호출하면 얻을 수 있는 데이터를 살펴보겠습니다. (이전에 exchange.SetContractType (rb1705) 를 호출하는 것을 기억하세요.

      [
          {"Time":1487034000000,"Open":3425,"High":3446,"Low":3423,"Close":3438,"Volume":177657.9999999999},
          {"Time":1487035800000,"Open":3438,"High":3448,"Low":3382,"Close":3385,"Volume":494882},
          {"Time":1487037600000,"Open":3385,"High":3398,"Low":3383,"Close":3394,"Volume":83656.00000000015}
      ]
      

      보이는 K선 데이터는 객체들의 배열이며, 각각의 객체는 Bar 사이클의 최고 가격, 최저 가격, 오픈 가격 (이 K선 시점의 시작 가격), 클로즈 가격 (이 K선 시점의 종료 가격), 거래량 (이 K선 사이클의 거래량) 을 포함하는 K선 바이다. 이 사이클은 K선 사이클이다. 예를 들어, 위의 배열의 데이터가 얼마나 큰 주기의 K 선인지 어떻게 결정합니까? 2 바의 시간 으로 계산할 수 있습니다: 1487035800000 - 1487034000000 이 값의 단위는 밀리 초입니다. 그래서 1800000 / 1000 / 60 = 30 (분), 이 K선 주기는 30분입니다.

      이 모든 것이 우리 삶에 영향을 미치고 있습니다. K줄 데이터를 사용할 때 배열 길이를 무시합니다. 이는 배열 접근 오차를 초래합니다. 이 유형의 BUG는 이전 C 프로그램을 작성할 때 자주 발생했습니다. 그래서 우리는 K줄을 사용하기 전에 그것에 대해 판단해야 합니다. 예를 들어, K선: exchange.SetContractType ((rb1705); // 스위치 설정은 스크로이트 스틸 1705 계약이다. var records = exchange.GetRecords ((); // rb1705 스кру트 스틸 계약의 기본 K 라인 주기 데이터를 얻는다. 얼마나 많은 바를 얻을 수 있는지에 대한 구체적인 K 라인 데이터는 거래소의 API가 추진하는 데에 따라 다릅니다. 따라서 초기에는 비교적 많은 K 라인 바가 필요하다면 프로그램이 수집하는 시간이 필요합니다. 그리고 프로그램 내에서 충분한 수집 여부를 판단하는 것은 다음과 같이 작성 될 수 있습니다.

      if(records.length < n){    // n 就是我们限定的 n线数量。
          return;                // 当前函数返回。
      }
      

      다른 문제도 있습니다. K 라인의 마지막 바의 데이터는 Time 속성, Open 속성, 그리고 Close 속성 이외의 다른 속성이 변경될 수 있으며 Close 속성은 실시간으로 변경됩니다. 초보자는 K선을 처리할 때 이해하지 못하기 때문에 많은 혼란을 겪을 수 있습니다. 예를 들어, 이전 장에서는 평선 교차에 대해 이야기했습니다.

      세 번째 질문: K선의 주기, 시간표는 이 주기의 시작점이며, 시간표는 밀리초수, 값은 0이다. 시간표는 1970년 1월 1일을 나타낸다. 이 문장은우리 학교또는 BotVS 샌드박스 시스템에서 테스트합니다.

      var arr = new Date(0);
      

      이 글은

      Thu Jan 01 1970 08:00:00 GMT+0800 (CST) // 표시되는 동시계 8 이 값은 1970년부터 현재까지 추가된 값입니다. (1초가 1000 밀리초이기 때문에 1초마다 1000을 더하기 때문에) 여기 작은 트릭이 있습니다: 시간표는 K선 주기의 K선에 있는 각 바가 고유하기 때문에, 시간표가 변경되면 최신 K선 데이터를 수신하는 것을 확인할 수 있습니다. 이것은 실제로 K선 데이터를 처리하는 데에도 유용합니다.

  • 2, 지표 호출 세부 사항, 자주 발생하는 문제 만족 주기, 반환 값, 매개 변수

    프로그램화 또는 계량화 정책을 작성할 때 많은 지표 함수가 사용된다. 비교적 유용한 지표 밸브에는 talib 밸브가 있다.

    바이트가 처음으로 지표库의 함수를 사용했을 때 많은 오류가 발생했습니다:

    • 첫 번째, 매개 변수 주기는 (매개 변수, K 라인 주기와 구별하여, K 라인 주기는 얼마이며, 계산된 지표 K 라인 주기는 얼마이며, 예를 들어 30 분 K 라인 계산된 것은 30 분 주기의 MACD 지표이며, 매개 변수 주기는) 너무 커 설정되어 K 라인 데이터 길이가 충분하지 않습니다: 예를 들어 MACD 지표는 다음과 같이 설명합니다.

      MACD(Records[Close],Fast Period = 12,Slow Period = 26,Signal Period = 9) = [Array(outMACD),Array(outMACDSignal),Array(outMACDHist)]
      

      사용시, 만약 변수 주기가 12,26,9로 설정되어 있다면, 우리는 지표를 계산하기 위해 K선 데이터 레코드를 입력합니다.

      var macd = talib.MACD(records, 12, 26, 9);
      

      이 때 입력된 기록의 길이가 너무 작다면, 계산은 다음과 같습니다.

      [
        [null,null,null,null,null,null,null,null,null,null,null,null,null],
        [null,null,null,null,null,null,null,null,null,null,null,null,null],
        [null,null,null,null,null,null,null,null,null,null,null,null,null]
      ]
      

      이것은 K 라인 데이터가 부족하기 때문에, 계산된 지표가 사용되면 BUG을 일으킬 수 있기 때문에, 우리는 프로그램 전에 한계 조건을 추가합니다:

      while(!records || records.length < 50){
          records = exchange.GetRecords();
          Sleep(1000);
      }
      

      50개의 K줄을 얻을 때까지 루프를 넘기세요.img

      주의 깊게 읽는 독자는 MACD가 계산되는 것이 한 줄이 아니라 세 줄이 있기 때문에 이 지표가 계산되는 데이터가 2차원 대수군 (즉, 하나의 대수군의 모든 요소는 또 다른 대수군) 임을 알 수 있습니다. 따라서 각 지표의 반환 값은 다를 수 있습니다.

      [
        [null,null,null,null,null,null,null,null,数据...],
        [null,null,null,null,null,null,null,null,数据...],
        [null,null,null,null,null,null,null,null,数据...]
      ]
      

      또한, 몇 번은 지표의 반환 구조에 주의를 기울이지 않아서 BUG가 발생합니다.

    • 두 번째, 지표 함수의 계산에 사용되는 평균선은 다르거나 지표 알고리즘이 다른 결과를 초래합니다.

      이 지표는 STOCH RSI와 비교해 볼 수 있습니다.

      STOCHRSI(Records[Close],Time Period = 14,Fast-K Period = 5,Fast-D Period = 3,Fast-D MA = 0) = [Array(outFastK),Array(outFastD)]
      

      이 계산된 값은 다른 알고리즘과 확연히 다르며, 이 지표는 이 시리즈의 첫 번째 장에서 제 자신의 알고리즘 코드를 제공합니다. 관심있는 독자들은 아래와 비교할 수 있습니다. 그 이유는 사용된 일평선 체계의 불일치로 인한 것일 수 있으며, 일부 도서의 알고리즘은 MA를 사용하며, 일부는 EMA를 사용한다. 일부 지표는 매일 반복적으로 계산되며, 주어진 K선 데이터의 수가 다르면 계산 값이 다를 수 있다.

  • 3, API가 오류를 처리합니다.

    • Cannot read property length?? of null 이 BUG는 가장 자주 발생하는 것 중 하나입니다.

      이 이유는 API가 때때로 다양한 이유로 데이터 획득 오류가 발생하거나 데이터를 얻지 못하는 경우가 있기 때문입니다. 이 경우 일부 데이터 획득 API는 null값을 얻습니다. 이 데이터는 일반적으로 배열 구조이며 종종 배열의 길이를 액세스해야합니다.

      모든 API 호출에 대해 오류 처리가 필요하며, 때로는 데이터가 정상인지 확인하는 것도 필요합니다. 우리의 프로그램은 자신의 코드에 대한 정확성을 보장 할 수 있습니다. 그러나 네트워크에서 돌아다니는 데이터 정보에 대해 100% 정확성을 보장 할 수 없습니다. 그래서 얻은 데이터에 대해 오류 처리가 필요하며 모든 오류 데이터를 필터링해야합니다.

      단 단계 디뷰, 단점 디뷰, 변수 값 모니터링 등이 없기 때문에 제가 보통 DEBUG하는 방법은 가장 간단한 로그법입니다. 프로그램 프로세스에서 논리적으로 로그 출력 텍스트 정보, 분석 프로그램 출력 로그를 사용하는 경우. 프로그램의 실행 과정을 알 수 있고 try, catch, throw JS의 예외 포착을 결합하여 BUG를 처리 할 수 있지만, 나는 예외 포착을 사용할 필요가 없을 때 사용하지 않는 것이 좋습니다. DEBUG의 경우, 가장 원시적인 로그 대법을 사용하는 것은 실제로 경험적인 일이고, DEBUG 능력을 키우는 관점에서 이것은 매우 효과적입니다. 어느 정도 축적되어 있으며, 어떤 BUG도 두려워하지 않습니다.

이 글을 쓰기 전에, 독자 저에게 편지를 보내십시오! 제안과 의견을 보내십시오. 재미있다면 더 많은 프로그램을 좋아하는 거래하는 친구에게 공유 할 수 있습니다.

https://www.fmz.com/bbs-topic/728

프로그래머 littleDream 원작


더 많은