거래 시스템 개발 c

기술 & amp; 양적 금융.

무역 시스템 소프트웨어 개발자 | 고주파 거래 | 낮은 대기 시간 시스템 | 시장 만들기 모델 | C / C ++

트레이딩 시스템은 어떻게 개발합니까?

종종 거래 모델 개발자는 프로세스 초기에 오류를 만들어 모델의 최종 결과를 "망칠"수 있습니다. 이러한 오류는 생존 편향을 고려하지 않고 수집 된 데이터를 잘못 사용하거나 비슷한 모델의 사양을 너무 많이 테스트 할 수 있습니다. 이와 같은 데이터 스누핑은 되돌릴 수없는 오류이므로 비용이 많이 듭니다. 따라서 아직 데이터 수집, 모델 지정 또는 백 테스트의 활발한 작업을 시작하지 않은 경우 테스트 및 개발 프로세스를 최적으로 수행 할 수있는 기회가 주어집니다.

트레이딩 모델 개발을 위해 저에게로 오는 고객들을 위해, 나는 우선 당신의 아이디어에 대한 개념적 이해를 얻고, 얼굴 타당성에 대한 전략을 조사 할 수 있도록 광범위한 논의를 시작하는 것이 효율적이라는 것을 알고 있습니다. 일단 당신의 가설을 편안하게 생각한다면, 나는 그 투자 이론을 모델로 한 모델을 시작할 것입니다. 모델을 개발하는이 초기 단계에서 필자는 모델이 데이터 스누핑 바이어스 또는 생존자 편향과 같은 금융 또는 포트폴리오 이론에서 표준 인 편견을 겪지 않도록 보장합니다. 너무 많은 모델을 테스트하지 않고 지나치게 지정되지 않은 강력한 전략을 사용하고 데이터 세트에서 비 생존자의 영향을 고려함으로써이 작업을 수행 할 것입니다.

여기에서 시스템에서 사용하는 거래 실행 방법에 대해 간략하게 논의합니다. 이 수단은 수동 거래 실행, 자동 거래 또는 둘의 조합 일 수 있습니다. 또한 절대 수익 또는 위험 조정 수익이 거래 모델의 목표가 될 것인지, 그리고 실시간으로 시스템을 백 테스트하고 교환하기 위해 필요한 데이터의 가용성에 대해서도 논의합니다.

트레이딩 모델의 핵심 목표를 이해하고, 정형 분석을 시작하기에 앞서, 모델을 개발하는 가장 효과적인 방법이라고 생각되는 것을 질적으로 설명합니다. 또한 모델의 특정 요구 사항에 따라 사용할 정량적 방법론에 대한 간략한 보고서를 제공합니다.

고객은 다양한 형태로 거래 시스템을 요청합니다. Ninjatrader, Tradestation, Metastock 또는 E-Signal과 같은 거래 소프트웨어 패키지에서 거래 될 수있는 모델을 개발할 수 있습니다. 그러나 당신이 당신의 거래 업무에 대해 진지한 사람이라면, C #이나 C ++와 같은 표준 프로그래밍 언어를 사용하여 자신의 트레이딩 시스템 / 플랫폼을 생성 할 것을 강력하게 권장합니다.

대부분의 거래 시스템은 강력한 백 테스팅 및 민감도 분석을 필요로하므로 신뢰할 수 있고 정리 된 데이터 세트를 갖는 것이 극히 중요합니다. 많은 고객이 거래를위한 실시간 데이터를 제공하는 외부 데이터 피드를 사용하지만 기록 데이터베이스는 포함하지 않습니다. 이러한 상황에서는보다 광범위한 백 테스팅을 수행하는 데 필요한 데이터를 보유하고 있거나 합리적인 비용으로 데이터를 수집 할 수 있습니다. 데이터가 사용하기 어려운 형식 인 경우 데이터 세트를 더 유용한 것으로 변환해야합니다. 비교적 새로운 유가 증권에 의존하는 시스템에서 작업하는 경우 데이터가 존재하지 않을 수 있습니다. 이 경우, 현재 사용할 수있는 것보다 더 다양한 경제 및 거래 환경을 통해 시스템을 테스트하는 데 사용할 수있는 대표적인 리턴 스트림을 구성하기 위해 귀하와 협력하게 될 것입니다.

트레이딩 모델의 백 테스팅 및 개발.

백 테스트는 모델 개발에서 가장 중요한 단계 중 하나입니다. 시험 절차의 긍정적 인 결과는 미래의 성공을 보장하는 것은 아니지만 최종 신호에 포함시키기위한 지표의 성공에 대한 충분한 증거가 있음을 나타냅니다. 물론 테스트 절차 중 커미션, 입찰 / 물가 스프레드, 판매량 및 기타 거래 비용 및 제한 사항을 고려합니다.

나의 주요 목표는 모든 일이 강력하고 완벽하게 복제 가능하다는 것입니다. 나는 당신이 모델의 지나치게 특정 버전을 만들거나, 수십 가지 지표를 테스트하거나, "좋아 보인다"는 것을 발견 할 때까지 동일한 핵심 모델의 여러 변형을 테스트함으로써 거래 이익을 창출하는 것을 돕지 않습니다. 트레이딩 시스템을 테스트하고 최적화하는 것은 종종 출판하는 학업에 대해, 학계에서 매일 개발되는 최첨단 전략에 대해, 또는 자신의 모델을 통해 부여합니다. 나는 강건하기 위해서 미리 전략을 명확히 명시 할 필요가 있고, 동일한 데이터 세트에 대해 다중 최적화 시도를 시도 할 수 없으며, 이와 같은 원칙을 위반하면 미래의 모델 수행에 대한 예측이 가치가 없을 것이라는 것을 이해합니다. 이 문제 (데이터 스누핑으로 인한 결과가 좋지 않음)는 거래자와 거래 모델을 개발할 계획을 논의 할 때 가장 큰 문제입니다. 많은 상인이 금융 시장 데이터에 나타날 수있는 편견을 완전히 이해하지 못하고 있습니다. 제대로 만들어진 트레이딩 모델은 과거뿐만 아니라 실시간으로 작동합니다.

위험 관리는 거래 시스템 개발의 가장 중요한 측면 중 하나입니다. 위치 결정, 출입, 출입 및 / 또는 레버리지가 차선 적으로 적용되면 이상적인 신호 생성 절차조차도 부정적인 결과를 초래할 수 있습니다. 모든 상인은 고유 한 위험 관용을 갖고 있으며, 고객과 함께 위험 관리 프로세스를 완전히 이해할 수 있도록 노력하고 있습니다. 시스템의 위험을 위험 허용 수준과 일치 시키도록 설계된 독점적 인 테스트 절차를 통해 귀하의 시스템을 운영합니다. 이러한 과정은 당신이 편안함을 잃을 위험을 최소화하거나 제거합니다. 우수한 시스템은 신호 개발 프로세스에서 각 변수의 통계적 분포에 대해 보수적이고 현실적이며 낙관적 인 시나리오를 추정해야합니다. 이러한 변수는 배포판 전체 범위에서 수백만 번 시뮬레이션되어 주어진 시간 단위로 시스템의 최대 이익과 손실을 명확하게 파악합니다. 또한 시뮬레이션 결과와 동일한 범위의 시스템에 대해 최대 드로 드로 다운 통계가 계산되고 그래픽으로 표시됩니다. 분석 결과를 논의한 후, 우리는 위험 허용도, 위치 조정 및 레버리지 사용을 고려합니다.

물론, 나는이 시점에서나 미래에서이 문제들에 관해 상담 할 수있다. 거래 모델은 기계로 수행 할 수 없습니다 (이것은 자동화 된 거래 시스템조차도 마찬가지입니다). 그들은 개념적으로 이해할 필요가 있습니다. 나는 당신이 그 개념적 이해를 가질 때까지 여전히 우리 중 많은 사람들에게 익숙한 교수의 역할로 당신과 함께 할 것입니다.

거래 모델 개발의 마지막 단계는 실행입니다. 수동 또는 자동 실행으로 이상적인 플랫폼을 선택할 수 있도록 도와 드리겠습니다. 수동 거래는 일반적으로 중장기 시스템을 위해 예약되어 있습니다. 정기적 인 광범위한 사용자 개입이 필요하기 때문입니다. 대조적으로, 단기 시스템은 자동화 된 거래 시스템이 대부분의 거래를 처리하기 때문에 더 적은 개입이 필요합니다. 다양한 트레이딩 소프트웨어 패키지가 있으며, 모두 자동화 된 트레이딩을 지원하지는 않습니다. 특정 시스템에 적합하지 않을 수 있습니다. 또한, 일부 패키지는 자동 거래가 가능하기 전에 심층 프로그래밍을 필요로합니다. 새로운 모델이 필요로하는 서비스를 정확하게 발견하고 현재의 시스템 및 운영에 선택 사항을 통합 할 수 있도록 도울 수 있습니다.

기밀성, 관계에서 가장 중요한 요소.

거래 모델이나 아이디어를 다룰 때 기밀성의 중요성과 필요성을 이해하고 모든 잠재 고객에게 연락시 즉시 비공개 계약을 제공합니다. 이를 통해 귀하의 아이디어 및 / 또는 기존 모델이 제 3 자와 공유되지 않으며 귀하와의 상담이 완전히 비밀이 보장됩니다.

이 공유:

소식 탐색.

거래 시스템 구축 - 일반 고려 사항.

$ SPY (S & amp; P 500) 백 테스팅 : SMA 10/100 시스템.

3 가지 생각 & ldquo; 트레이딩 시스템은 어떻게 개발합니까? & rdquo;

소매 사용자를위한 Forex 또는 Futures에서 HFT 시스템의 예를 어디에서 찾을 수 있습니까? 100k $ 계정이없고 수수료는 1 $ 🙂

소매 수준에서 알릴 수는 없습니까? & # 8230;

그러나 조심하십시오, 이것은 소매 수준에서 아무 HFT도 아닙니다 & # 8230; 소매 업체에게는 수수료가 너무 높으며 인프라가 뒤떨어져 있습니다.

회신을 남겨주 답장을 취소하십시오.

최근 게시물.

최근 댓글.

카테고리.

거래 시스템, 양적 금융, 고주파 거래, HFT, 저 대기 시간 시스템, 전자 시장 만들기.

현대 이벤트 기반 아키텍처.

선택한 개발 환경을 사용하여 표준 C ++ 11에서 강력한 거래 시스템을 개발하십시오. 모델링 할 수있는 거래 시스템의 복잡성에는 제한이 없습니다.

고급보고 및 분석.

광범위한 반복적 인 보고서를 통해 거래 시스템의 모든 측면에 대한 심층적 인 통찰력을 얻으십시오. 모든 시뮬레이션 결과는 파일로 저장되며 분석하고 다른 시뮬레이션 결과와 비교할 수 있습니다. 성과, 위험 및 수익을 분석하고 차트를 탐색하십시오.

Timeseries 언어 확장.

전용 언어 확장 (내장 된 도메인 특정 언어)이있는 시계열을 모델링합니다. 필요한 경우 람다 함수로 보완 할 수있는 직관적 인 함수 구문을 사용하여 지표를 개발하십시오.

멀티 악기 거래 시스템.

다른 유형의 조합을 포함하여 모든 계측기 구성원을 선언하십시오. 이것은 거래 바구니, 퍼짐 및 intermarket 관계를 추적하는 것을 허용한다. 보고서는 개별 계측기뿐만 아니라 집계 기준으로도 사용할 수 있습니다.

소스 코드를 이용한 쉬운 디버깅.

거래 시스템은 쉽게 시작하고 디버그 할 수 있습니다. 이들은 개별 실행 파일로 실행됩니다. 원하는 개발 환경과 디버거를 사용하여 코드를 단계별 실행하십시오. API는 소스 코드와 함께 제공됩니다.

자동화 된 무역 시스템 구축.

1 판.

Visual C ++ 2005 소개.

기관 접근.

보안 체크 아웃.

무료 배송.

최소 주문이 없습니다.

목차.

1 장 소개.

섹션 I : Visual C ++ 2005 소개.

2 장 프레임 워크.

3 장 추적 참조.

4 장 클래스와 객체.

5 장 참조 유형.

6 장 값 유형.

7 장 관리되지 않는 객체.

제 8 장 구도.

9 장 속성.

10 장 구조와 열거.

제 11 장 상속.

12 장 변환 및 캐스팅.

13 장 연산자 오버로딩.

제 14 장 대리인 및 행사.

15 장 배열.

16 장 난수 생성.

17 장 시간과 타이머.

18 장 입출력 스트림.

19 장 예외 처리.

20 장 컬렉션.

21 장 STL / STL.

22 장 데이터 세트.

23 장 데이터베이스 연결.

24 장 구조화 된 쿼리 언어.

26 장 재무 정보 교환 프로토콜.

27 장 직렬화.

28 장 Windows 서비스.

29 장 설치 및 설치 패키지.

섹션 II : 동시성.

30 장 스레딩.

31 장 동기화 클래스.

32 장 소켓.

섹션 III : 상호 운용성 및 연결성.

33 장 마샬링.

34 장 내부 및 고정 포인터.

35 장 관리되는 DLL에 연결.

36 COM Interop를 사용하여 COM (구성 요소 개체 모델) DLL에 연결.

37 장 플랫폼 호출 서비스로 C ++ DLL에 연결.

38 장 Excel에 연결.

39 장 TraderAPI에 연결.

40 장 XTAPIC 연결에 연결 _ 예.

섹션 IV : 자동화 된 거래 시스템.

제 41 장 무역 시스템 구축.

제 42 장 K "V 무역 시스템 개발 방법론.

43 장 자동화 된 거래 시스템 클래스.

44 장 단일 스레드, 기술적 분석 시스템.

제 45 장 생산자 / 소비자 디자인 패턴.

Chapter 46 다중 스레드, 통계적 차용 시스템.

기술.

향후 몇 년 동안 독점 트레이딩 및 헤지 펀드 산업은 자동화 된 무역 선택 및 집행 시스템으로 크게 옮겨 갈 것입니다. 실제로 이것은 이미 일어나고 있습니다. 여러 금융 서적이 파생 상품 가격 책정 및 수치 계산 수행을위한 C ++ 코드를 제공하지만 시스템 디자인 관점에서 주제를 다루는 책은 없습니다. 이 책은 프로그래밍 기술과 ATS (automated trading system) 기술의 두 섹션으로 나누어 져 있으며 Microsoft Visual C ++ 2005를 사용하여 금융 시스템 설계 및 개발을 절대적으로 가르칩니다. Microsoft Visual C ++ 2005는 주로 구현 언어로 선택되었습니다. 대부분의 무역 회사와 대형 은행이 ISO C ++에서 독점 알고리즘을 개발하고 계속 개발하고 있기 때문에 Visual C ++는 이러한 레거시 알고리즘을 작업 시스템에 통합 할 때 가장 큰 유연성을 제공합니다. 또한 프레임 워크 및 개발 환경은 거래 시스템의 신속한 개발을위한 최상의 라이브러리 및 도구를 제공합니다. 이 책의 첫 번째 섹션에서는 Visual C ++ 2005에 대해 자세히 설명하고 STL을 사용하여 개체 지향 디자인, 대리자 및 이벤트, 열거, 난수 생성, 타이밍 및 타이머 개체 및 데이터 관리를 비롯한 자동화 된 거래 시스템 개발에 필요한 프로그래밍 지식에 중점을 둡니다. 및 컬렉션. 또한 금융 시장의 대부분의 레거시 코드 및 모델링 코드는 ISO C ++로 작성되었으므로이 책에서는 관리 / 비 관리 / COM 메모리 관리 및 상호 운용성과 관련된 몇 가지 고급 주제를 자세하게 살펴 봅니다. 또한이 책은 ADO와의 데이터베이스 연결 사용과 SQL, FIX 및 XML / FIXML의 광범위한 처리를 보여주는 수십 가지 예제를 제공합니다. 스레딩, 소켓 및 C ++을 사용하여 Excel에 연결하는 것과 같은 고급 프로그래밍 항목에 대해서도 자세히 논의하고 예제를 통해 지원합니다. 이 책의 두 번째 섹션에서는 자동화 된 거래 시스템에 대한 기술적 관심과 디자인 개념에 대해 설명합니다. 특히, 챕터는 실시간 데이터 피드 처리, 교환 주문서의 주문 관리, 위치 선택 및 위험 관리에 전념합니다..dll은 널리 사용되는 산업 API (Trading Technologies, Inc. 의 XTAPI)와의 연결을 에뮬레이트하고 위치 및 주문 관리 알고리즘을 테스트하는 방법을 제공하는 책에 포함되어 있습니다. 디자인 패턴은 기술 분석뿐만 아니라 시장 간판을 사용하여 시장을 만드는 시스템을 기반으로하는 시장 획득 시스템을 위해 제공됩니다. 모든 장이 금융 공학 및 거래 시스템 개발을위한 컴퓨터 프로그래밍을 중심으로 진행되기 때문에이 책은 상인, 금융 엔지니어, 양적 분석가, 양적 금융 학생, Microsoft의 금융 응용 프로그램 개발을 중심으로하는 기술적 인 문제에 대해 숙련 된 프로그래머까지 교육 할 것입니다. 환경 및 실시간 거래 시스템 및 도구의 구축 및 구현

주요 특징들.

Microsoft Visual C ++ 2005를 사용하여 재무 시스템 설계 및 개발 과정을 철저히 가르칩니다.

이 책의 프로그래밍 방식을 보여주는 수십 가지 예제를 제공합니다.

독자층.

주요 대상 : 금융 엔지니어, 정량 분석가, 무역 회사의 프로그래머 금융 공학 및 금융 시장 과정 및 프로그램의 대학원생.

리뷰.

"자동화 된 트레이딩 시스템 구축은 전문 알고리즘 트레이딩 시스템을 개발하는 모든 사람들에게 필수적이며, 디자인, 기능 및 실시간 시스템 구현의 모든 측면을 단계별로 명확하게 제시합니다. 트레이딩 시스템 개발에있어 진지한 전문 프로그래머. " - Russell Wojcik, CME 및 CBOT, 일리노이 공과 대학 무역 전략 센터 책임자 "이 책은 자동화 또는 반자동 거래 응용 프로그램 개발에 관심이있는 모든 사람들에게 훌륭한 입문서입니다. Ben은 성공적인 개발에 필요한 프로그래밍 지식을 다룹니다 트레이더들이 프로그래밍에 뛰어 들어야하고 프로그래머들이 트레이딩에 참여해야하며, 보다 정교한 트레이딩 툴을 개발할 때 유용한 참고 자료가 될 것 "이라고 말했다. - Sagy P. Mintz, Trading Technologies, Inc. 의 부사장

평점 및 리뷰.

저자 정보

Benjamin Van Vliet 저자.

Ben Van Vliet은 일리노이 공과 대학 (IIT)의 강사로 M. S.의 부국장을 맡고 있습니다. 금융 시장 프로그램. IIT에서 그는 양적 금융, C ++ 및 프로그래밍, 자동화 된 거래 시스템 설계 및 개발 과정을 가르칩니다. 그는 시장 기술 연구소의 부회장으로 CTSD (Certified Trading System Developer) 프로그램 자문위원회 의장을 맡고 있습니다. 또한 Elsevier / Academic Press의 금융 시장 기술 시리즈 시리즈 편집자로도 활동하며 금융 시장 업계에서 광범위하게 컨설팅을 수행합니다.

Van Vliet은 또한 Robert Hendry (2003, McGraw Hill)와 "Automated Trading System"(2007, Academic Press)과 함께 "금융 시장 모델링"의 저자이기도하며 재무 및 기술 분야의 여러 기사를 발표했습니다 여러 학술 및 전문 컨퍼런스에서 그의 연구를 발표했습니다.

제휴 및 전문성.

미국 일리노이 공과 대학의 스튜어트 스쿨 오브 비즈니스 (Stuart School of Business) 금융 시장 프로그램 석사 및 부교수.

견적 요청.

세금 면제.

제품 & amp; 솔루션 R & amp; D 솔루션 임상 솔루션 연구 플랫폼 연구 인텔리전스 교육 서비스 저자 편집자 리뷰 사서 사서 샵 & amp; 도서 및 저널 발견 저자 웹샵 Elsevier 소개 Elsevier Connect 채용 정보 어떻게 도울 수 있습니까? 지원 센터.

어떻게 도와 드릴까요?

어떻게 도와 드릴까요?

저작권 및 사본; 2017 Elsevier, 제 3자가 제공 한 특정 내용은 제외.

쿠키는이 사이트에서 사용됩니다. 거부하거나 더 자세히 알아 보려면 쿠키 페이지를 방문하십시오.

Elsevier 방문자 설문 조사.

우리는 항상 Elsevier의 고객 경험을 향상시킬 수있는 방법을 모색하고 있습니다.

방문이 끝나면 간단한 설문지 작성 시간에 관해 묻고 싶습니다.

QuantStart.

빠르게 성장하는 소매점 퀀텀 트레이더 커뮤니티를 지원하는 Quantcademy 개인 회원 포털에 가입하십시오. 당신은 당신의 가장 중요한 퀀트 트레이딩 질문에 대답 할 준비가되어있는 지식이 풍부하고 마음이 맞는 퀀트 트레이더 그룹을 찾을 수 있습니다.

퀀트 트레이딩에 관한 나의 eBook을 확인해보십시오. 여기서 저는 파이썬 툴로 수익성 높은 체계적인 트레이딩 전략을 만드는 법을 가르쳐드립니다.

Python 및 R을 사용하여 시계열 분석, 기계 학습 및 베이지안 통계를 사용하는 고급 거래 전략에 관한 새로운 전자 책을 살펴보십시오.

2013 년 7 월 26 일 Michael Halls-Moore 작성

QS mailbag에서받는 가장 자주 묻는 질문 중 하나는 "알고리즘 트레이딩을위한 최고의 프로그래밍 언어는 무엇입니까?"입니다. 짧은 대답은 "최상의"언어가 없다는 것입니다. 전략 매개 변수, 성능, 모듈성, 개발, 탄력성 및 비용을 모두 고려해야합니다. 이 기사는 알고리즘 트레이딩 시스템 아키텍처의 필수 구성 요소와 구현에 관한 결정이 언어 선택에 미치는 영향을 설명합니다.

첫째, 리서치 툴, 포트폴리오 옵티 마이저, 리스크 관리자 및 실행 엔진과 같은 알고리즘 트레이딩 시스템의 주요 구성 요소를 고려합니다. 이후에 서로 다른 트레이딩 전략을 검토하고 이들이 시스템의 설계에 어떻게 영향을 주는지에 대해 조사 할 것입니다. 특히 거래 빈도와 거래량에 대해 모두 논의 할 것입니다.

거래 전략이 선택되면 전체 시스템을 설계해야합니다. 여기에는 희소하고 잠재적으로 치명적인 이벤트에 대한 하드웨어, 운영 체제 및 시스템 탄력성의 선택이 포함됩니다. 아키텍처가 고려되는 동안 연구 도구뿐 아니라 실제 실행 환경에 대해서도 성능에 대한 적절한 고려가 이루어져야합니다.

무역 시스템은 무엇을하려고합니까?

자동화 된 거래 시스템을 작성하는 "최상의"언어를 결정하기 전에 요구 사항을 정의해야합니다. 시스템이 순전히 실행 기반이 될 것입니까? 시스템에 위험 관리 또는 포트폴리오 구성 모듈이 필요합니까? 시스템에 고성능 백 테스터가 필요합니까? 대부분의 전략에서 거래 시스템은 연구 및 신호 생성이라는 두 가지 범주로 나눌 수 있습니다.

연구는 과거 데이터에 대한 전략 성과 평가와 관련이 있습니다. 이전 시장 데이터에 대한 거래 전략을 평가하는 프로세스를 백 테스팅 (backtesting)이라고합니다. 데이터 크기와 알고리즘 복잡성은 백 테스터의 계산 강도에 큰 영향을 미칩니다. CPU 속도와 동시성은 종종 연구 실행 속도를 최적화하는데있어 제한 요소입니다.

신호 생성은 알고리즘으로부터 일련의 거래 신호를 생성하고 그러한 주문을 보통 중개를 통해 시장에 보내는 것과 관련이 있습니다. 특정 전략의 경우 높은 수준의 성과가 요구됩니다. 네트워크 대역폭 및 대기 시간과 같은 I / O 문제는 종종 실행 시스템 최적화의 제한 요소입니다. 따라서 전체 시스템의 각 구성 요소에 대한 언어 선택은 상당히 다를 수 있습니다.

유형, 빈도 및 전략의 양.

채택 된 알고리즘 전략의 유형은 시스템 설계에 상당한 영향을 미칩니다. 거래되는 시장, 외부 데이터 공급 업체와의 연결성, 전략의 빈도 및 양, 개발 용이성과 성능 최적화 간의 균형, 공동 배치 된 사용자 지정을 포함한 모든 사용자 지정 하드웨어를 고려해야합니다 서버, GPU 또는 FPGA가 필요합니다.

저주파 미국 주식 전략의 기술 선택은 선물 시장에서 거래하는 고주파 통계적 재정 거래 전략의 기술 선택과 크게 다를 것입니다. 언어를 선택하기 전에 많은 데이터 공급 업체가 현재 진행중인 전략과 관련이 있는지 평가해야합니다.

오프라인 상태에서 공급 업체와의 연결, API의 구조, 데이터의 적시성, 저장소 요구 사항 및 복원력을 고려해야합니다. 또한 여러 공급 업체에 신속하게 액세스 할 수있는 것이 현명합니다. 다양한 계측기에는 모두 자신 만의 스토리지 쿼크가 있으며, 여기에는 주식에 대한 여러 시세 표시와 선물에 대한 만료일이 포함됩니다 (특정 OTC 데이터는 말할 것도 없습니다). 이를 플랫폼 설계에 고려해야합니다.

전략의 빈도는 기술 스택 정의 방법의 가장 큰 동인 중 하나 일 수 있습니다. 미세하거나 두 번째 막대보다 자주 데이터를 사용하는 전략은 성과와 관련하여 중대한 고려 사항이 필요합니다.

두 번째 막대 (예 : 틱 데이터)를 초과하는 전략은 주요 요구 사항으로 성능 중심의 디자인을 유도합니다. 고 빈도 전략의 경우 상당량의 시장 데이터를 저장하고 평가해야합니다. HDF5 또는 kdb +와 같은 소프트웨어가 일반적으로 이러한 역할에 사용됩니다.

HFT 응용 프로그램에 필요한 대량의 데이터를 처리하려면 광범위하게 최적화 된 백 테스터 및 실행 시스템을 사용해야합니다. C / C ++ (일부 어셈블러 사용 가능)이 가장 강력한 언어 후보가 될 가능성이 큽니다. 초고주파 전략에는 FPGA, 교환기 위치 및 커널 / 네트워크 인터페이스 튜닝과 같은 맞춤형 하드웨어가 거의 필요합니다.

연구 시스템.

연구 시스템에는 대개 대화 형 개발과 자동화 된 스크립팅이 혼합되어 있습니다. 전자는 종종 Visual Studio, MatLab 또는 R Studio와 같은 IDE 내에서 발생합니다. 후자는 수많은 매개 변수와 데이터 포인트에 대한 광범위한 수치 계산을 포함합니다. 따라서 코드를 테스트 할 수있는 간단한 환경을 제공하는 언어 선택이 가능하지만 여러 매개 변수 차원에서 전략을 평가하는 데 충분한 성능을 제공합니다.

이 분야의 일반적인 IDE에는 광범위한 디버깅 유틸리티, "Intellisense"를 통한 코드 완성 기능 및 데이터베이스 ORM, LINQ를 통한 전체 프로젝트 스택의 간단한 개요가 포함 된 Microsoft Visual C ++ / C #이 포함됩니다. 광범위한 수치 선형 대수 및 벡터화 연산을 위해 설계된 대화식 콘솔 방식의 MatLab; R Studio는 R 통계 언어 콘솔을 본격적인 IDE에 랩핑합니다. Linux 용 Eclipse IDE Java 및 C ++; NumPy, SciPy, scikit-learn 및 pandas와 같은 데이터 분석 라이브러리를 단일 대화 형 (콘솔) 환경에 포함하는 Enthought Canopy for Python과 같은 반 독점 IDE가 있습니다.

숫자 백 테스트의 경우 위의 모든 언어가 적합하지만 코드가 백그라운드에서 실행되므로 GUI / IDE를 사용할 필요는 없습니다. 이 단계에서 가장 중요한 고려 사항은 실행 속도입니다. 컴파일 된 언어 (예 : C ++)는 백 테스트 매개 변수 크기가 큰 경우에 유용합니다. 그러한 경우 그러한 시스템을 조심하는 것이 필요하다는 것을 기억하십시오!

Python과 같은 해석 언어는 컴파일 된 등가물과의 합리적인 수준의 경쟁력을 유지하기 위해 백 테스팅 단계에 NumPy / pandas와 같은 고성능 라이브러리를 사용합니다. 궁극적으로 백 테스팅을 위해 선택한 언어는 특정 알고리즘 요구 사항과 언어에서 사용할 수있는 라이브러리 범위 (아래에서 자세히 설명)에 따라 결정됩니다. 그러나 백 테스터 및 연구 환경에 사용되는 언어는 포트폴리오 구성, 위험 관리 및 실행 구성 요소에서 사용되는 언어와 완전히 독립적 일 수 있습니다.

포트폴리오 구축 및 리스크 관리.

포트폴리오 구성 및 위험 관리 구성 요소는 종종 소매 알고리즘 거래자에 의해 간과됩니다. 이것은 거의 항상 실수입니다. 이 도구들은 자본이 보존되는 메커니즘을 제공합니다. 그들은 "위험한"배팅의 수를 줄이려고 시도 할뿐만 아니라 거래 자체의 이탈을 최소화하여 거래 비용을 줄입니다.

이러한 구성 요소의 정교한 버전은 품질 및 일관성있는 수익성에 중요한 영향을 미칩니다. 포트폴리오 구축 메커니즘 및 리스크 관리자가 여러 시스템을 처리하기 위해 쉽게 수정 될 수 있으므로 안정적인 전략을 수립하는 것은 간단합니다. 따라서 이들은 알고리즘 거래 시스템의 설계 초기에 필수 구성 요소로 간주되어야합니다.

포트폴리오 건설 시스템의 일은 일련의 원하는 거래를 수행하고 해지를 최소화하고 다양한 요인 (예 : 부문, 자산 클래스, 변동성 등)에 대한 노출을 유지하고 다양한 자본 배분을 최적화하는 실제 거래 세트를 생성하는 것입니다 포트폴리오의 전략.

포트폴리오 구축은 종종 선형 대수 문제 (예 : 행렬 인수 분해)로 축소되므로 성능은 사용 가능한 수치 선형 대수 구현의 효율성에 크게 의존합니다. 공통 라이브러리에는 uBLAS, LAPACK 및 CAG 용 NAG가 포함됩니다. MatLab은 또한 광범위하게 최적화 된 매트릭스 연산을 보유합니다. 파이썬은 그러한 계산을 위해 NumPy / SciPy를 사용합니다. 빈번하게 재조정 된 포트폴리오는 거래 시스템에 병목 현상이 발생하지 않도록이 단계를 수행하기 위해 컴파일 된 (그리고 최적화 된!) 매트릭스 라이브러리가 필요합니다.

위험 관리는 알고리즘 거래 시스템의 또 다른 매우 중요한 부분입니다. 위험은 여러 가지 형태로 나타날 수 있습니다 : 변동성 증가 (특정 전략에서는 바람직 함), 자산 클래스, 거래 상대 디폴트, 서버 중단, "Black Swan"이벤트 및 거래 코드의 탐지되지 않은 버그 간의 상관 관계 증가, 몇 가지 예를 들자면

위험 관리 구성 요소는 과도한 변동성 및 자산 클래스와 후속 효과의 거래 자본에 대한 상관 관계를 시도하고 예상합니다. 종종 이것은 Monte Carlo "스트레스 테스트"와 같은 일련의 통계 계산으로 축소됩니다. 이는 파생 상품 가격 책정 엔진의 계산 요구와 매우 유사하며 CPU와 관련이 있습니다. 이러한 시뮬레이션은 고도로 병렬 처리가 가능하며 (아래 참조) 어느 정도는 "하드웨어를 문제에 던지기"가 가능합니다.

실행 시스템.

실행 시스템의 임무는 포트폴리오 구성 및 위험 관리 구성 요소에서 필터링 된 거래 신호를 수령하여 중개 또는 기타 시장 접근 수단으로 보내는 것입니다. 대부분의 소매 알고리즘 거래 전략의 경우 인터랙티브 브로커 (Interactive Brokers)와 같은 중개 회사에 API 또는 FIX 연결이 필요합니다. 언어를 결정할 때 주요 고려 사항은 API의 품질, API의 언어 래퍼 가용성, 실행 빈도 및 예상 미끄러짐을 포함합니다.

API의 "품질"은 문서의 종류, 제공되는 성능의 종류, 액세스 할 독립형 소프트웨어가 필요한지 또는 게이트웨이가 헤드리스 방식 (즉, GUI 없음)으로 설정 될 수 있는지 여부를 나타냅니다. 대화 형 중개인의 경우 Trader WorkStation 도구는 API에 액세스하기 위해 GUI 환경에서 실행되어야합니다. 한때 데스크톱 우분투 에디션을 아마존 클라우드 서버에 설치해야만 인터랙티브 브로커에 원격으로 액세스 할 수있었습니다.

대부분의 API는 C ++ 및 / 또는 Java 인터페이스를 제공합니다. 일반적으로 C #, Python, R, Excel 및 MatLab에 대한 언어 별 래퍼를 개발하는 것은 커뮤니티의 몫입니다. 활용되는 추가 플러그인 (특히 API 래퍼)마다 버그가 시스템에 들어가는 범위가 있음에 유의하십시오. 이러한 종류의 플러그인을 항상 테스트하고 플러그인을 유지 관리해야합니다. 가치있는 계기는 최근 몇 개월 동안 코드베이스에 대한 새로운 업데이트가 몇 번 있었는지 확인하는 것입니다.

실행 빈도는 실행 알고리즘에서 가장 중요합니다. 매주 수백 건의 주문이 보내질 수 있으며 이러한 성능은 중요합니다. 부실 실행 집행 시스템을 통해 미끄러짐이 발생하며 이는 수익성에 큰 영향을 미칩니다.

일반적으로 C ++ / Java와 같은 정적 유형 언어 (아래 참조)는 일반적으로 실행하기에 최적이지만 개발 시간, 테스트 및 유지 관리 용이성이 절충됩니다. 파이썬과 펄과 같이 동적으로 유형화 된 언어는 이제 일반적으로 "충분히 빠름"입니다. 구성 요소가 모듈 방식으로 설계되어 있는지 확인하십시오 (아래 참조). 시스템 구성에 따라 구성 요소를 "교체"할 수 있습니다.

건축 계획 및 개발 프로세스.

거래 시스템의 구성 요소, 빈도 및 볼륨 요구 사항은 위에서 논의했지만 시스템 인프라는 아직 다루지 않았습니다. 소매 상인이나 작은 펀드에서 일하는 사람들은 "많은 모자를 쓰고 있습니다"라고합니다. 알파 모델, 위험 관리 및 실행 매개 변수, 그리고 시스템의 최종 구현을 포괄해야합니다. 특정 언어를 탐구하기 전에 최적의 시스템 아키텍처 설계가 논의 될 것입니다.

우려의 분리.

가장 먼저해야 할 가장 중요한 결정 중 하나는 거래 시스템의 "우려 사항을 어떻게 분리 할 것인가"입니다. 소프트웨어 개발에서 이것은 본질적으로 거래 시스템의 다른 측면을 개별 모듈 구성 요소로 분해하는 방법을 의미합니다.

각 구성 요소에서 인터페이스를 노출하면 외부 종속성 코드를 수정하지 않고도 성능, 안정성 또는 유지 관리를 돕는 다른 버전의 시스템 부분을 쉽게 교체 할 수 있습니다. 이러한 시스템에 대한 "우수 사례"입니다. 낮은 빈도의 전략에 대해서는 이러한 관행을 권고합니다. 극도로 높은 빈도로 거래하는 경우, 더 나은 성능을 위해 시스템을 조정하는 대신 규칙 책을 무시해야합니다. 보다 밀접하게 결합 된 시스템이 바람직 할 수 있습니다.

알고리즘 거래 시스템의 구성 요소지도를 만드는 것은 그 자체만으로 가치가 있습니다. 그러나 최적의 접근 방식은 과거 및 실시간 시장 데이터 입력, 데이터 저장, 데이터 액세스 API, 백 테스터, 전략 매개 변수, 포트폴리오 구성, 위험 관리 및 자동화 된 실행 시스템을위한 별도의 구성 요소가 있는지 확인하는 것입니다.

For instance, if the data store being used is currently underperforming, even at significant levels of optimisation, it can be swapped out with minimal rewrites to the data ingestion or data access API. As far the as the backtester and subsequent components are concerned, there is no difference.

Another benefit of separated components is that it allows a variety of programming languages to be used in the overall system. There is no need to be restricted to a single language if the communication method of the components is language independent. This will be the case if they are communicating via TCP/IP, ZeroMQ or some other language-independent protocol.

As a concrete example, consider the case of a backtesting system being written in C++ for "number crunching" performance, while the portfolio manager and execution systems are written in Python using SciPy and IBPy.

Performance Considerations.

Performance is a significant consideration for most trading strategies. For higher frequency strategies it is the most important factor. "Performance" covers a wide range of issues, such as algorithmic execution speed, network latency, bandwidth, data I/O, concurrency/parallelism and scaling. Each of these areas are individually covered by large textbooks, so this article will only scratch the surface of each topic. Architecture and language choice will now be discussed in terms of their effects on performance.

The prevailing wisdom as stated by Donald Knuth, one of the fathers of Computer Science, is that "premature optimisation is the root of all evil". This is almost always the case - except when building a high frequency trading algorithm! For those who are interested in lower frequency strategies, a common approach is to build a system in the simplest way possible and only optimise as bottlenecks begin to appear.

Profiling tools are used to determine where bottlenecks arise. Profiles can be made for all of the factors listed above, either in a MS Windows or Linux environment. There are many operating system and language tools available to do so, as well as third party utilities. Language choice will now be discussed in the context of performance.

C++, Java, Python, R and MatLab all contain high-performance libraries (either as part of their standard or externally) for basic data structure and algorithmic work. C++ ships with the Standard Template Library, while Python contains NumPy/SciPy. Common mathematical tasks are to be found in these libraries and it is rarely beneficial to write a new implementation.

One exception is if highly customised hardware architecture is required and an algorithm is making extensive use of proprietary extensions (such as custom caches). However, often "reinvention of the wheel" wastes time that could be better spent developing and optimising other parts of the trading infrastructure. Development time is extremely precious especially in the context of sole developers.

Latency is often an issue of the execution system as the research tools are usually situated on the same machine. For the former, latency can occur at multiple points along the execution path. Databases must be consulted (disk/network latency), signals must be generated (operating syste, kernal messaging latency), trade signals sent (NIC latency) and orders processed (exchange systems internal latency).

For higher frequency operations it is necessary to become intimately familiar with kernal optimisation as well as optimisation of network transmission. This is a deep area and is significantly beyond the scope of the article but if an UHFT algorithm is desired then be aware of the depth of knowledge required!

Caching is very useful in the toolkit of a quantitative trading developer. Caching refers to the concept of storing frequently accessed data in a manner which allows higher-performance access, at the expense of potential staleness of the data. A common use case occurs in web development when taking data from a disk-backed relational database and putting it into memory. Any subsequent requests for the data do not have to "hit the database" and so performance gains can be significant.

For trading situations caching can be extremely beneficial. For instance, the current state of a strategy portfolio can be stored in a cache until it is rebalanced, such that the list doesn't need to be regenerated upon each loop of the trading algorithm. Such regeneration is likely to be a high CPU or disk I/O operation.

However, caching is not without its own issues. Regeneration of cache data all at once, due to the volatilie nature of cache storage, can place significant demand on infrastructure. Another issue is dog-piling , where multiple generations of a new cache copy are carried out under extremely high load, which leads to cascade failure.

Dynamic memory allocation is an expensive operation in software execution. Thus it is imperative for higher performance trading applications to be well-aware how memory is being allocated and deallocated during program flow. Newer language standards such as Java, C# and Python all perform automatic garbage collection , which refers to deallocation of dynamically allocated memory when objects go out of scope .

Garbage collection is extremely useful during development as it reduces errors and aids readability. However, it is often sub-optimal for certain high frequency trading strategies. Custom garbage collection is often desired for these cases. In Java, for instance, by tuning the garbage collector and heap configuration, it is possible to obtain high performance for HFT strategies.

C++ doesn't provide a native garbage collector and so it is necessary to handle all memory allocation/deallocation as part of an object's implementation. While potentially error prone (potentially leading to dangling pointers) it is extremely useful to have fine-grained control of how objects appear on the heap for certain applications. When choosing a language make sure to study how the garbage collector works and whether it can be modified to optimise for a particular use case.

Many operations in algorithmic trading systems are amenable to parallelisation . This refers to the concept of carrying out multiple programmatic operations at the same time, i. e in "parallel". So-called "embarassingly parallel" algorithms include steps that can be computed fully independently of other steps. Certain statistical operations, such as Monte Carlo simulations, are a good example of embarassingly parallel algorithms as each random draw and subsequent path operation can be computed without knowledge of other paths.

Other algorithms are only partially parallelisable. Fluid dynamics simulations are such an example, where the domain of computation can be subdivided, but ultimately these domains must communicate with each other and thus the operations are partially sequential. Parallelisable algorithms are subject to Amdahl's Law, which provides a theoretical upper limit to the performance increase of a parallelised algorithm when subject to $N$ separate processes (e. g. on a CPU core or thread ).

Parallelisation has become increasingly important as a means of optimisation since processor clock-speeds have stagnated, as newer processors contain many cores with which to perform parallel calculations. The rise of consumer graphics hardware (predominently for video games) has lead to the development of Graphical Processing Units (GPUs), which contain hundreds of "cores" for highly concurrent operations. Such GPUs are now very affordable. High-level frameworks, such as Nvidia's CUDA have lead to widespread adoption in academia and finance.

Such GPU hardware is generally only suitable for the research aspect of quantitative finance, whereas other more specialised hardware (including Field-Programmable Gate Arrays - FPGAs) are used for (U)HFT. Nowadays, most modern langauges support a degree of concurrency/multithreading. Thus it is straightforward to optimise a backtester, since all calculations are generally independent of the others.

Scaling in software engineering and operations refers to the ability of the system to handle consistently increasing loads in the form of greater requests, higher processor usage and more memory allocation. In algorithmic trading a strategy is able to scale if it can accept larger quantities of capital and still produce consistent returns. The trading technology stack scales if it can endure larger trade volumes and increased latency, without bottlenecking .

While systems must be designed to scale, it is often hard to predict beforehand where a bottleneck will occur. Rigourous logging, testing, profiling and monitoring will aid greatly in allowing a system to scale. Languages themselves are often described as "unscalable". This is usually the result of misinformation, rather than hard fact. It is the total technology stack that should be ascertained for scalability, not the language. Clearly certain languages have greater performance than others in particular use cases, but one language is never "better" than another in every sense.

One means of managing scale is to separate concerns, as stated above. In order to further introduce the ability to handle "spikes" in the system (i. e. sudden volatility which triggers a raft of trades), it is useful to create a "message queuing architecture". This simply means placing a message queue system between components so that orders are "stacked up" if a certain component is unable to process many requests.

Rather than requests being lost they are simply kept in a stack until the message is handled. This is particularly useful for sending trades to an execution engine. If the engine is suffering under heavy latency then it will back up trades. A queue between the trade signal generator and the execution API will alleviate this issue at the expense of potential trade slippage. A well-respected open source message queue broker is RabbitMQ.

Hardware and Operating Systems.

The hardware running your strategy can have a significant impact on the profitability of your algorithm. This is not an issue restricted to high frequency traders either. A poor choice in hardware and operating system can lead to a machine crash or reboot at the most inopportune moment. Thus it is necessary to consider where your application will reside. The choice is generally between a personal desktop machine, a remote server, a "cloud" provider or an exchange co-located server.

Desktop machines are simple to install and administer, especially with newer user friendly operating systems such as Windows 7/8, Mac OSX and Ubuntu. Desktop systems do possess some significant drawbacks, however. The foremost is that the versions of operating systems designed for desktop machines are likely to require reboots/patching (and often at the worst of times!). They also use up more computational resources by the virtue of requiring a graphical user interface (GUI).

Utilising hardware in a home (or local office) environment can lead to internet connectivity and power uptime problems. The main benefit of a desktop system is that significant computational horsepower can be purchased for the fraction of the cost of a remote dedicated server (or cloud based system) of comparable speed.

A dedicated server or cloud-based machine, while often more expensive than a desktop option, allows for more significant redundancy infrastructure, such as automated data backups, the ability to more straightforwardly ensure uptime and remote monitoring. They are harder to administer since they require the ability to use remote login capabilities of the operating system.

In Windows this is generally via the GUI Remote Desktop Protocol (RDP). In Unix-based systems the command-line Secure SHell (SSH) is used. Unix-based server infrastructure is almost always command-line based which immediately renders GUI-based programming tools (such as MatLab or Excel) to be unusable.

A co-located server, as the phrase is used in the capital markets, is simply a dedicated server that resides within an exchange in order to reduce latency of the trading algorithm. This is absolutely necessary for certain high frequency trading strategies, which rely on low latency in order to generate alpha.

The final aspect to hardware choice and the choice of programming language is platform-independence. Is there a need for the code to run across multiple different operating systems? Is the code designed to be run on a particular type of processor architecture, such as the Intel x86/x64 or will it be possible to execute on RISC processors such as those manufactured by ARM? These issues will be highly dependent upon the frequency and type of strategy being implemented.

Resilience and Testing.

One of the best ways to lose a lot of money on algorithmic trading is to create a system with no resiliency . This refers to the durability of the sytem when subject to rare events, such as brokerage bankruptcies, sudden excess volatility, region-wide downtime for a cloud server provider or the accidental deletion of an entire trading database. Years of profits can be eliminated within seconds with a poorly-designed architecture. It is absolutely essential to consider issues such as debuggng, testing, logging, backups, high-availability and monitoring as core components of your system.

It is likely that in any reasonably complicated custom quantitative trading application at least 50% of development time will be spent on debugging, testing and maintenance.

Nearly all programming languages either ship with an associated debugger or possess well-respected third-party alternatives. In essence, a debugger allows execution of a program with insertion of arbitrary break points in the code path, which temporarily halt execution in order to investigate the state of the system. The main benefit of debugging is that it is possible to investigate the behaviour of code prior to a known crash point .

Debugging is an essential component in the toolbox for analysing programming errors. However, they are more widely used in compiled languages such as C++ or Java, as interpreted languages such as Python are often easier to debug due to fewer LOC and less verbose statements. Despite this tendency Python does ship with the pdb, which is a sophisticated debugging tool. The Microsoft Visual C++ IDE possesses extensive GUI debugging utilities, while for the command line Linux C++ programmer, the gdb debugger exists.

Testing in software development refers to the process of applying known parameters and results to specific functions, methods and objects within a codebase, in order to simulate behaviour and evaluate multiple code-paths, helping to ensure that a system behaves as it should. A more recent paradigm is known as Test Driven Development (TDD), where test code is developed against a specified interface with no implementation. Prior to the completion of the actual codebase all tests will fail. As code is written to "fill in the blanks", the tests will eventually all pass, at which point development should cease.

TDD requires extensive upfront specification design as well as a healthy degree of discipline in order to carry out successfully. In C++, Boost provides a unit testing framework. In Java, the JUnit library exists to fulfill the same purpose. Python also has the unittest module as part of the standard library. Many other languages possess unit testing frameworks and often there are multiple options.

In a production environment, sophisticated logging is absolutely essential. Logging refers to the process of outputting messages, with various degrees of severity, regarding execution behaviour of a system to a flat file or database. Logs are a "first line of attack" when hunting for unexpected program runtime behaviour. Unfortunately the shortcomings of a logging system tend only to be discovered after the fact! As with backups discussed below, a logging system should be given due consideration BEFORE a system is designed.

Both Microsoft Windows and Linux come with extensive system logging capability and programming languages tend to ship with standard logging libraries that cover most use cases. It is often wise to centralise logging information in order to analyse it at a later date, since it can often lead to ideas about improving performance or error reduction, which will almost certainly have a positive impact on your trading returns.

While logging of a system will provide information about what has transpired in the past, monitoring of an application will provide insight into what is happening right now . All aspects of the system should be considered for monitoring. System level metrics such as disk usage, available memory, network bandwidth and CPU usage provide basic load information.

Trading metrics such as abnormal prices/volume, sudden rapid drawdowns and account exposure for different sectors/markets should also be continuously monitored. Further, a threshold system should be instigated that provides notification when certain metrics are breached, elevating the notification method (, SMS, automated phone call) depending upon the severity of the metric.

System monitoring is often the domain of the system administrator or operations manager. However, as a sole trading developer, these metrics must be established as part of the larger design. Many solutions for monitoring exist: proprietary, hosted and open source, which allow extensive customisation of metrics for a particular use case.

Backups and high availability should be prime concerns of a trading system. Consider the following two questions: 1) If an entire production database of market data and trading history was deleted (without backups) how would the research and execution algorithm be affected? 2) If the trading system suffers an outage for an extended period (with open positions) how would account equity and ongoing profitability be affected? The answers to both of these questions are often sobering!

It is imperative to put in place a system for backing up data and also for testing the restoration of such data. Many individuals do not test a restore strategy. If recovery from a crash has not been tested in a safe environment, what guarantees exist that restoration will be available at the worst possible moment?

Similarly, high availability needs to be "baked in from the start". Redundant infrastructure (even at additional expense) must always be considered, as the cost of downtime is likely to far outweigh the ongoing maintenance cost of such systems. I won't delve too deeply into this topic as it is a large area, but make sure it is one of the first considerations given to your trading system.

Choosing a Language.

Considerable detail has now been provided on the various factors that arise when developing a custom high-performance algorithmic trading system. The next stage is to discuss how programming languages are generally categorised.

Type Systems.

When choosing a language for a trading stack it is necessary to consider the type system . The languages which are of interest for algorithmic trading are either statically - or dynamically-typed . A statically-typed language performs checks of the types (e. g. integers, floats, custom classes etc) during the compilation process. Such languages include C++ and Java. A dynamically-typed language performs the majority of its type-checking at runtime. Such languages include Python, Perl and JavaScript.

For a highly numerical system such as an algorithmic trading engine, type-checking at compile time can be extremely beneficial, as it can eliminate many bugs that would otherwise lead to numerical errors. However, type-checking doesn't catch everything, and this is where exception handling comes in due to the necessity of having to handle unexpected operations. 'Dynamic' languages (i. e. those that are dynamically-typed) can often lead to run-time errors that would otherwise be caught with a compilation-time type-check. For this reason, the concept of TDD (see above) and unit testing arose which, when carried out correctly, often provides more safety than compile-time checking alone.

Another benefit of statically-typed languages is that the compiler is able to make many optimisations that are otherwise unavailable to the dynamically - typed language, simply because the type (and thus memory requirements) are known at compile-time. In fact, part of the inefficiency of many dynamically-typed languages stems from the fact that certain objects must be type-inspected at run-time and this carries a performance hit. Libraries for dynamic languages, such as NumPy/SciPy alleviate this issue due to enforcing a type within arrays.

Open Source or Proprietary?

One of the biggest choices available to an algorithmic trading developer is whether to use proprietary (commercial) or open source technologies. There are advantages and disadvantages to both approaches. It is necessary to consider how well a language is supported, the activity of the community surrounding a language, ease of installation and maintenance, quality of the documentation and any licensing/maintenance costs.

The Microsoft stack (including Visual C++, Visual C#) and MathWorks' MatLab are two of the larger proprietary choices for developing custom algorithmic trading software. Both tools have had significant "battle testing" in the financial space, with the former making up the predominant software stack for investment banking trading infrastructure and the latter being heavily used for quantitative trading research within investment funds.

Microsoft and MathWorks both provide extensive high quality documentation for their products. Further, the communities surrounding each tool are very large with active web forums for both. The software allows cohesive integration with multiple languages such as C++, C# and VB, as well as easy linkage to other Microsoft products such as the SQL Server database via LINQ. MatLab also has many plugins/libraries (some free, some commercial) for nearly any quantitative research domain.

There are also drawbacks. With either piece of software the costs are not insignificant for a lone trader (although Microsoft does provide entry-level version of Visual Studio for free). Microsoft tools "play well" with each other, but integrate less well with external code. Visual Studio must also be executed on Microsoft Windows, which is arguably far less performant than an equivalent Linux server which is optimally tuned.

MatLab also lacks a few key plugins such as a good wrapper around the Interactive Brokers API, one of the few brokers amenable to high-performance algorithmic trading. The main issue with proprietary products is the lack of availability of the source code. This means that if ultra performance is truly required, both of these tools will be far less attractive.

Open source tools have been industry grade for sometime. Much of the alternative asset space makes extensive use of open-source Linux, MySQL/PostgreSQL, Python, R, C++ and Java in high-performance production roles. However, they are far from restricted to this domain. Python and R, in particular, contain a wealth of extensive numerical libraries for performing nearly any type of data analysis imaginable, often at execution speeds comparable to compiled languages, with certain caveats.

The main benefit of using interpreted languages is the speed of development time. Python and R require far fewer lines of code (LOC) to achieve similar functionality, principally due to the extensive libraries. Further, they often allow interactive console based development, rapidly reducing the iterative development process.

Given that time as a developer is extremely valuable, and execution speed often less so (unless in the HFT space), it is worth giving extensive consideration to an open source technology stack. Python and R possess significant development communities and are extremely well supported, due to their popularity. Documentation is excellent and bugs (at least for core libraries) remain scarce.

Open source tools often suffer from a lack of a dedicated commercial support contract and run optimally on systems with less-forgiving user interfaces. A typical Linux server (such as Ubuntu) will often be fully command-line oriented. In addition, Python and R can be slow for certain execution tasks. There are mechanisms for integrating with C++ in order to improve execution speeds, but it requires some experience in multi-language programming.

While proprietary software is not immune from dependency/versioning issues it is far less common to have to deal with incorrect library versions in such environments. Open source operating systems such as Linux can be trickier to administer.

I will venture my personal opinion here and state that I build all of my trading tools with open source technologies. In particular I use: Ubuntu, MySQL, Python, C++ and R. The maturity, community size, ability to "dig deep" if problems occur and lower total cost ownership (TCO) far outweigh the simplicity of proprietary GUIs and easier installations. Having said that, Microsoft Visual Studio (especially for C++) is a fantastic Integrated Development Environment (IDE) which I would also highly recommend.

Batteries Included?

The header of this section refers to the "out of the box" capabilities of the language - what libraries does it contain and how good are they? This is where mature languages have an advantage over newer variants. C++, Java and Python all now possess extensive libraries for network programming, HTTP, operating system interaction, GUIs, regular expressions (regex), iteration and basic algorithms.

C++ is famed for its Standard Template Library (STL) which contains a wealth of high performance data structures and algorithms "for free". Python is known for being able to communicate with nearly any other type of system/protocol (especially the web), mostly through its own standard library. R has a wealth of statistical and econometric tools built in, while MatLab is extremely optimised for any numerical linear algebra code (which can be found in portfolio optimisation and derivatives pricing, for instance).

Outside of the standard libraries, C++ makes use of the Boost library, which fills in the "missing parts" of the standard library. In fact, many parts of Boost made it into the TR1 standard and subsequently are available in the C++11 spec, including native support for lambda expressions and concurrency.

Python has the high performance NumPy/SciPy/Pandas data analysis library combination, which has gained widespread acceptance for algorithmic trading research. Further, high-performance plugins exist for access to the main relational databases, such as MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) and psychopg2 (PostgreSQL/Python). Python can even communicate with R via the RPy plugin!

An often overlooked aspect of a trading system while in the initial research and design stage is the connectivity to a broker API. Most APIs natively support C++ and Java, but some also support C# and Python, either directly or with community-provided wrapper code to the C++ APIs. In particular, Interactive Brokers can be connected to via the IBPy plugin. If high-performance is required, brokerages will support the FIX protocol.

결론.

As is now evident, the choice of programming language(s) for an algorithmic trading system is not straightforward and requires deep thought. The main considerations are performance, ease of development, resiliency and testing, separation of concerns, familiarity, maintenance, source code availability, licensing costs and maturity of libraries.

The benefit of a separated architecture is that it allows languages to be "plugged in" for different aspects of a trading stack, as and when requirements change. A trading system is an evolving tool and it is likely that any language choices will evolve along with it.

양적 거래 시작하기?

QuantStart 목록을 구독해야하는 3 가지 이유 :

1. 퀀트 트레이딩 레슨.

계량 거래를 시작하는 데 도움이되는 힌트와 팁으로 가득한 무료 10 일간 코스에 즉시 액세스 할 수 있습니다!

2. All The Latest Content.

매주 나는 퀀트 스타트에서 모든 활동의 포장을 보내드릴 것입니다. 그래서 당신은 결코 다시 글을 놓치지 않을 것입니다.

현실감 넘치는 퀀 트레이딩 팁.