Amibroker 거래 시스템 설계

ami 중개인.
AmiBroker의 강력하고 초고속 탐색 도구를 사용하여 시장에서 기회와 비효율을 검색하십시오.
목표 항목 정의 & amp; 거래에서 감정을 제거하는 규칙을 종료하십시오. 포트폴리오 수준의 백 테스팅 & amp; 성능을 미세 조정하기위한 최적화. Walk-forward & amp; 몬테카를로 시뮬레이션.
차트에서 시각적으로 거래하거나 분석 도구를 사용하여 주문 목록을 생성하거나 자동 거래 인터페이스를 사용하여 코드에서 직접 주문합니다. 당신의 스타일이 무엇이든간에. 너의 선택이야.
거래를 다음 단계로 업그레이드하십시오.
강력하고 사용하기 쉽고 아름다운 차트.
드래그 앤 드롭 평균, 밴드 및 기타 표시기의 표시기, 슬라이더를 사용하여 실시간으로 매개 변수 수정 및 다양한 스타일 & amp; 그라디언트를 아름답게 만듭니다.
세계에서 가장 빠른 포트폴리오 백 테스팅 및 최적화.
탁월한 속도는 고급 위치 결정, 점수 및 순위, 순환 거래, 맞춤 측정 항목, 맞춤 백 테스터, 복수 통화 지원과 같은 정교한 기능과 함께 제공됩니다.
자동화 및 일괄 처리.
반복되는 작업에 시간과 노력을 낭비하지 마십시오. AmiBroker가 새로 통합 된 배치 프로세서를 사용하여 일상 업무를 자동화하게하십시오. 지루한 반복 클릭이 없습니다. AmiBroker가 잠자는 동안 작동 할 수 있도록 Windows 스케줄러에서 실행할 수 있습니다.
모든 정보를 손쉽게 찾아 볼 수 있습니다.
이것은 탐험을 사용하여 할 수있는 많은 것들 중 하나 일뿐입니다.
분석 창은 백 테스트, 최적화, 워크 포워드 테스트 및 몬테카를로 시뮬레이션의 본거지입니다.
시스템 트레이더를위한 강력한 도구.
분석 창.
분석 창은 모든 스캔, 탐색, 포트폴리오 백 테스트, 최적화, 워크 포워드 테스트 및 몬테카를로 시뮬레이션의 본거지입니다.
시장에서 기회를 탐색하십시오.
Exploration은 모든 기호 데이터에서 행 및 열을 무제한으로 완벽하게 프로그래밍 할 수있는 표 형식 출력을 생성하는 다목적 스크리닝 / 데이터 마이닝 도구입니다.
시스템을 테스트하십시오.
Backtest는 기록 데이터에 대한 시스템 성능을 테스트 할 수 있습니다. 시뮬레이션은 실제와 마찬가지로 포트폴리오 수준에서 수행되며, 동시에 거래되는 여러 증권이 각각 사용자 정의 가능한 포지션 사이징 규칙을 가지고 있습니다.
득점 & amp; 순위.
동일한 바에 여러 입력 신호가 발생하고 구매력이 부족한 경우 AmiBroker는 선호 거래를 찾기 위해 사용자가 지정할 수있는 위치 점수를 기반으로 bar-by-bar 랭킹을 수행합니다.
최적의 매개 변수 값을 찾으십시오.
AmiBroker에게 수천 개의 서로 다른 매개 변수 조합을 시도하여 실적이 가장 우수한 매개 변수 조합을 찾으라고 알려주십시오. 제한된 시간에 거대한 공간을 검색하려면 Smart Artificial Intelligence Optimization (Particle Swarm 및 CMA-ES)을 사용하십시오.
워크 포워드 테스트.
과도한 함정에 빠지지 마십시오. 샘플 내 최적화 프로세스 후 Out-of-Sample 성능을 확인하여 시스템의 견고성을 검증하십시오.
몬테카를로 시뮬레이션.
어려운 시장 상황에 대비하십시오. 최악의 시나리오와 파손 확률을 확인하십시오. 거래 시스템의 통계 특성에 대한 통찰력을 얻으십시오.
간결하고 빠른 수식 언어로 거래 아이디어를 표현하십시오.
패스트 배열 및 매트릭스 처리.
AmiBroker Formula Language (AFL) 벡터 및 행렬은 일반 숫자와 같은 기본 유형입니다. 하이와 로우 어레이의 중간 점을 원소 단위로 계산하려면 MidPt = (H + L) / 2를 입력하면됩니다. // H와 L은 배열이고 벡터화 된 컴퓨터 코드로 컴파일됩니다. 루프를 작성할 필요가 없습니다. 따라서 어셈블러에서 작성된 코드와 동일한 속도로 수식을 실행할 수 있습니다. 기본 고속 행렬 연산자 및 함수를 사용하면 통계 계산을 쉽게 수행 할 수 있습니다.
간결한 언어는 더 적은 작업을 의미합니다.
AFL로 작성된 거래 시스템과 지표는 AFL의 많은 일반적인 작업이 단일 라이너이기 때문에 다른 언어보다 타이핑이 적고 공간이 적습니다. 예를 들어 동적 인 ATR 기반 샹들리에의 중지는 단지 ApplyStop (stopTypeTrailing, stopModePoint, 3 * ATR (14), True, True);
내장 디버거.
디버거를 사용하면 코드를 한 단계 건너 뛰고 런타임에 변수를 관찰하여 수식이하는 일을 더 잘 이해할 수 있습니다.
최첨단 코드 편집기.
구문 강조, 자동 완성, 매개 변수 호출 팁, 코드 접기, 자동 들여 쓰기 및 인라인 오류보고 기능을 갖춘 고급 편집기를 사용하십시오. 오류가 발생하면 의미있는 메시지가 오른쪽에 표시되어 눈을 피로하게하지 않습니다.
적은 타이핑, 더 빠른 결과.
바로 사용할 수있는 Code 스 니펫으로 수식을 코딩하는 것이 결코 쉬운 일은 아닙니다. 일반적인 코딩 작업과 패턴을 구현하는 수십 개의 사전 작성된 스 니펫을 사용하거나 자신의 스 니펫을 만드십시오!
멀티 스레딩.
모든 수식에는 여러 프로세서 / 코어가 자동으로 적용됩니다. 각 차트 수식, 그래픽 렌더러 및 모든 분석 창은 별도의 스레드에서 실행됩니다.
선택할 수있는 3 가지 AmiBroker 에디션.
일반용.
End-of-day 및 스윙 트레이더를위한 엔트리 레벨 버전. 끝과 실시간. 1 분 간격으로 시작하는 일중. 실시간 견적 윈도우에서 10 개의 기호가 제한됩니다. 분석 창당 2 개의 동시 스레드. 32 비트 전용.
프로페셔널 에디션.
고급 백 테스팅 및 최적화 기능을 갖춘 전문 리얼 타임 및 분석 플랫폼. 끝과 실시간. 모든 Intraday Tick / Second / Minute 간격, 실시간 견적 창에서 무제한 기호. Time & amp; Sales의 기호는 무제한입니다. MAE / MFE 통계가 포함되어 있습니다. 분석 창당 최대 32 개의 동시 스레드. 64 비트 및 32 비트 버전을 모두 포함합니다.
Ultimate Pack Pro.
AmiBroker Professional Edition에는 다음과 같은 두 가지 유용한 프로그램이 있습니다.
AmiQuote - 무료 EOD와 일중 데이터 및 무료 기본 데이터를 갖춘 여러 온라인 소스에서 다운로더를 견적합니다.
AFL 코드 마법사 - 일반 영어 문장으로 AFL 수식을 만듭니다. 초보자를위한 귀중한 학습 도구. (AmiQuote 및 AFL Code Wizard 라이센스는 별도로 구입할 경우 $ 198의 가치가 있으므로이 팩을 구입할 때 8 %를 절약 할 수 있습니다)
시스템 요구 사항 : Microsoft Windows 10, 8.1, 7, Vista, XP, 2000, 최소 512MB RAM. Apple Mac 사용자는 Bootcamp / Parallels / VMWare를 사용하여 AmiBroker를 실행할 수 있습니다.
회사 소개 브랜드 소개 & amp; 조건 개인 정보 보호 정책 Us & # x2709; 문서 기능 목록 새로운 기능 사용자 가이드 데이터 소스 동영상 지원 기술 지원 & amp; 영업 멤버 영역 지식 데이터베이스 DevLog 사용자 KB 기타 AmiBroker YahooGroup 유용한 링크.
이 사이트는 쿠키를 사용합니다. 이 사이트를 탐색하면 개인 정보 보호 정책에 동의하게됩니다. 쿠키 정책.

아미 브로커 거래 시스템 디자인
참고 : 이것은 상당히 고급 주제입니다. 먼저 이전 AFL 자습서를 읽으십시오.
최적화의 기본 개념은 간단합니다. 먼저 거래 시스템을 가져야합니다. 예를 들어 단순한 이동 평균 크로스 오버가 될 수 있습니다. 거의 모든 시스템에는 주어진 시스템의 동작 방식을 결정하는 몇 가지 매개 변수 (평균 기간)가 있습니다 (예 : 장기 또는 단기에 적합, 변동성이 큰 주식에 어떻게 반응하는지 등). 최적화는 주어진 기호 (또는 기호 포트폴리오)에 대해 해당 매개 변수의 최적 값을 찾는 프로세스입니다 (시스템에서 최대 이익을 얻음). AmiBroker는 한 번에 여러 기호로 시스템을 최적화 할 수있는 아주 소수의 프로그램 중 하나입니다.
시스템을 최적화하려면 최적화 할 매개 변수를 최대 10 개까지 정의해야합니다. 매개 변수의 최소값과 최대 값을 결정하고이 값을 갱신해야하는 단위를 결정합니다. 그런 다음 AmiBroker는 매개 변수 값의 가능한 모든 조합을 사용하여 시스템에서 다중 백 테스트를 수행합니다. 이 프로세스가 완료되면 AmiBroker는 순이익별로 정렬 된 결과 목록을 표시합니다. 최상의 결과를 제공하는 최적화 매개 변수의 값을 볼 수 있습니다.
AFL 수식 작성.
백 테스터의 최적화는 새로운 기능인 최적화를 통해 지원됩니다. 이 함수의 구문은 다음과 같습니다.
변수 - 최적화 함수에 의해 반환 된 값이 할당되는 일반 AFL 변수입니다.
일반적인 backtesting, scanning, exploration 및 comentary 모드에서는 optimize 함수가 기본값을 리턴하므로 위의 함수 호출은 다음과 같습니다. variable = default;
최적화 모드에서 최적화 함수는 스텝 스테핑을 사용하여 최소값에서 최대 값까지 (연속적으로) 연속적인 값을 반환합니다.
& quot; 설명 & quot; 최적화 변수를 식별하는 데 사용되며 최적화 결과 목록에 열 이름으로 표시되는 문자열입니다.
기본값은 탐색, 표시기, 주석, 스캔 및 일반 백 테스트 모드에서 함수 반환을 최적화하는 기본값입니다.
min은 최적화되는 변수의 최소값입니다.
max는 최적화되는 변수의 최대 값입니다.
step은 min에서 max로 값을 증가시키는 데 사용되는 간격입니다.
AmiBroker는 함수를 최적화하기 위해 최대 64 개의 호출을 지원하므로 (최대 64 개의 최적화 변수까지), 철저한 최적화를 사용하는 경우 최적화 변수의 수를 소수로 제한하는 것이 좋습니다. 최적화를위한 각 호출은 생성 (최대 - 최소) / 단계 최적화 루프와 최적화를위한 다중 호출을 통해 필요한 실행 횟수를 곱합니다. 예를 들어 10 단계를 사용하여 두 개의 매개 변수를 최적화하려면 10 * 10 = 100 최적화 루프가 필요합니다. 각 호출이 새로운 최적화 루프를 생성 할 때 수식의 시작 부분에서 변수 당 오직 한 번만 호출하십시오. 다중 심볼 최적화는 AmiBroker가 완벽하게 지원합니다. 최대 검색 공간은 2 64 (10 19 = 10,000,000,000,000,000,000) 조합입니다.
1. 단일 변수 최적화 :
sigavg = 최적화 ( "신호 평균", 9, 2, 20, 1);
매도 = 십자가 (신호 (12, 26, sigavg), MACD (12, 26));
2. 2 변수 최적화 (3D 차트 작성에 적합)
per = Optimize ( "per", 2, 5, 50, 1);
Level = Optimize ( "level", 2, 2, 150, 4);
매도 = 십자가 (수준, CCI (당));
3. 다중 (3) 변수 최적화 :
mfast = 최적화 ( "MACD Fast", 12, 8, 16, 1);
mslow = 최적화 ( "MACD Slow", 26, 17, 30, 1);
sigavg = 최적화 ( "신호 평균", 9, 2, 20, 1);
구입 = 십자가 (MACD (mfast, mslow), 신호 (mfast, mslow, sigavg));
매도 = 십자가 (신호 (mfast, mslow, sigavg), MACD (mfast, mslow));
수식 입력 후 & quot; 자동 분석 & quot;에서 최적화 버튼을 클릭하십시오. 창문. AmiBroker는 가능한 모든 최적화 변수의 조합을 테스트하고 결과를 목록에보고합니다. 최적화가 완료되면 결과 목록이 Net % 이익별로 정렬되어 표시됩니다. 결과 목록에서 결과를 정렬 할 수 있기 때문에 최저 손익, 최저 거래 횟수, 최대 이익 요인, 최저 시장 노출 및 최고 위험 조정 연간 수익률에 대한 매개 변수의 최적 값을 쉽게 얻을 수 있습니다. 결과 목록의 마지막 열은 주어진 테스트의 최적화 변수 값을 나타냅니다.
필요에 맞는 매개 변수 조합을 결정할 때 최적의 함수 호출의 기본값을 최적의 값으로 바꾸면됩니다. 현재 단계에서 직접 수식 편집 창 (함수 호출 최적화 함수의 두 번째 매개 변수)에 직접 입력해야합니다.
3D 애니메이션 최적화 차트 표시.
3D 최적화 차트를 표시하려면 먼저 두 변수 최적화를 실행해야합니다. 두 개의 변수 최적화에는 두 개의 Optimize () 함수 호출이있는 수식이 필요합니다. 예제 2 변수 최적화 공식은 다음과 같습니다.
per = Optimize ( "per", 2, 5, 50, 1);
Level = Optimize ( "level", 2, 2, 150, 4);
매도 = 십자가 (수준, CCI (당));
수식을 입력 한 후 & quot; 최적화 & quot;를 클릭해야합니다. 단추.
최적화가 완료되면 최적화 버튼의 드롭 다운 화살표를 클릭하고 3D 최적화 그래프보기를 선택해야합니다. 몇 초 안에 다채로운 3 차원 표면 플롯이 3D 차트 뷰어 창에 나타납니다. 위 공식을 사용하여 생성 된 3D 차트의 예가 아래와 같습니다.
기본적으로 3D 차트에는 최적화 변수에 대한 순 이익의 값이 표시됩니다. 그러나 최적화 결과 테이블의 모든 열에 대해 3D 표면 형 차트를 그릴 수 있습니다. 열 헤더를 클릭하여 정렬하십시오 (파란색 화살표가 나타나 최적화 결과가 선택된 열로 정렬됨을 나타냄). 그런 다음 3D 최적화 그래프보기를 다시 선택하십시오.
시스템의 매개 변수가 거래 실적에 미치는 영향을 시각화함으로써 "깨지기 쉬운"매개 변수를 생성하는 매개 변수 값을보다 쉽게 ​​결정할 수 있습니다. 및 "견고한" 시스템 성능. 견고한 설정은 3D 그래프에서 서페이스 플롯의 갑작스러운 변화가 아닌 점진적인 영역을 나타냅니다. 3D 최적화 차트는 커브 피팅을 방지하는 훌륭한 도구입니다. 커브 피팅 (또는 과다 최적화)은 시스템이 필요한 것보다 더 복잡 할 때 발생하며, 이러한 복잡성은 결코 다시는 발생할 수없는 시장 상황에 초점을 맞추고 있습니다. 3D 최적화 차트의 급격한 변화 (또는 스파이크)는 최적화 최적화되지 않은 영역을 명확하게 보여줍니다. 실제 거래를 위해 3D 차트에서 넓고 넓은 고원을 생산하는 매개 변수 영역을 선택해야합니다. 이익 급증을 일으키는 매개 변수 세트는 실제 거래에서 안정적으로 작동하지 않습니다.
3D 차트 뷰어 컨트롤.
AmiBroker의 3D 차트 뷰어는 전체 그래프 회전과 애니메이션으로 전체보기 기능을 제공합니다. 이제 모든 가능한 관점에서 시스템 결과를 볼 수 있습니다. 마우스, 툴바 및 키보드 단축키를 사용하여보다 쉽게 ​​찾을 수있는 차트의 위치 및 기타 매개 변수를 제어 할 수 있습니다. 아래에서 목록을 찾을 수 있습니다.
- 회전하려면 - 왼쪽 마우스 버튼을 누른 상태에서 X / Y 방향으로 움직입니다.
- 확대, 축소 - 마우스 오른쪽 버튼을 누른 상태에서 X / Y 방향으로 이동합니다.
- 이동 (번역) - 왼쪽 마우스 버튼과 CTRL 키를 누른 상태에서 X / Y 방향으로 이동합니다.
- 애니메이트하려면 - 왼쪽 마우스 버튼을 누른 상태에서 드래그하면서 빠르게 드래그하고 버튼을 놓습니다.
공간 - 애니메이션 효과 (자동 회전)
왼쪽 화살표 키 - 회전합니다. 왼쪽.
오른쪽 화살표 키 - vert. 권리.
화살표 키 - 회전합니다. 쪽으로.
아래쪽 화살표 키 - 수평선을 회전합니다. 하위.
NUMPAD + (더하기) - 근처 (확대)
NUMPAD - (MINUS) - 멀리 (축소)
NUMPAD 4 - 왼쪽으로 이동합니다.
NUMPAD 6 - 오른쪽으로 이동하십시오.
NUMPAD 8 - 위로 이동하십시오.
NUMPAD 2 - 아래로 이동하십시오.
PAGE UP - 수위 상승.
PAGE DOWN - 수위가 내려갑니다.
스마트 한 (비 철저한) 최적화.
AmiBroker는 이제 정규적이고 철저한 검색 외에도 스마트 한 (비 철저한) 최적화 기능을 제공합니다. 비 포괄적 검색은 주어진 거래 시스템의 모든 매개 변수 조합의 수가 단순히 너무 커서 포괄적 인 검색이 가능하지 않은 경우 유용합니다.
철저한 검색은 사용하기에 합당한 한 완벽하게 훌륭합니다. 1에서 100까지 범위가 각각 2 개의 매개 변수가 있다고 가정 해 보겠습니다 (1 단계).
10000 개의 조합입니다. 철저한 검색으로 완벽하게 사용할 수 있습니다. 이제 3 개의 매개 변수를 사용하면 1 백만 가지 조합을 얻을 수 있습니다. 철저한 검색은 여전히 ​​유효하지만 길이는 길어질 수 있습니다. 4 개의 매개 변수로 1 억 개의 조합을 가지며 5 개의 매개 변수 (1..100)를 사용하면 100 억 개의 조합을 가질 수 있습니다. 이 경우 모든 항목을 검사하는 데 너무 많은 시간이 걸릴 수 있으며, 이는 철저한 검색을 사용하여 합리적인 시간에 해결할 수없는 문제를 비 철저한 스마트 검색 방법으로 해결할 수있는 영역입니다.
여기에 새로운 비 철저한 옵티 마이저 (이 경우 CMA-ES)를 사용하는 방법에 대한 간단한 설명이 있습니다.
1. 수식 편집기에서 수식을 엽니 다.
2.이 한 줄을 수식의 맨 위에 추가하십시오 :
OptimizerSetEngine ( "cmae"); // & quot; spso & quot;를 사용할 수도 있습니다. 또는 "trib" 이리.
3. (선택 사항) 자동 분석, 설정, & quot; 도보로 이동 & quot;에서 최적화 대상을 선택하십시오. 탭, 최적화 대상 필드. 이 단계를 건너 뛰면 CAR / MDD (복합 연간 수익률을 최대 % 하락률로 나눈 값)로 최적화됩니다.
이제이 공식을 사용하여 최적화를 실행하면 새로운 진화 (비 포괄적) CMA-ES 옵티 마이저가 사용됩니다.
어떻게 작동합니까?
최적화는 주어진 함수의 최소 (또는 최대)를 찾는 과정입니다. 모든 거래 시스템은 특정 수의 인수의 함수로 간주 될 수 있습니다. 입력은 매개 변수 및 견적 데이터이며 출력은 최적화 대상입니다.
(CAR / MDD). 그리고 주어진 기능의 최대를 찾고 있습니다.
일부 스마트 최적화 알고리즘은 자연 (동물 행동) - PSO 알고리즘 또는 생물학적 프로세스 - 유전자 알고리즘,
일부는 인간이 파생 한 수학적 개념 인 CMA-ES를 기반으로합니다.
이러한 알고리즘은 금융을 포함하여 다양한 분야에서 사용됩니다. & quot; PSO finance & quot;를 입력하십시오. 또는 "CMA-ES finance" Google에서는 많은 정보를 찾을 수 있습니다.
비 - 철저 (또는 "스마트") 방법은 글로벌 또는 로컬 최적을 발견 할 것이다. 목표는 물론 글로벌 목표를 찾는 것입니다. 단 하나의 첨예 한 피크가있는 경우입니다.
zillions 매개 변수 조합 중 비 - 철저한 방법은이 단일 피크를 찾지 못할 수도 있지만, 그 결과를 불안정하고 너무 실제 거래에서 복제 할 수 없기 때문에 단일 날카로운 피크를 찾는 것은 거래에 쓸모가 없습니다. 최적화 과정에서 우리는 안정된 파라미터를 가진 고원 지대를 찾고 있으며 지능적인 방법이 빛나는 영역입니다.
비 - 철저한 검색에 의해 사용 된 알고리즘은 다음과 같습니다 :
a) 옵티마이 저는 매개 변수 세트의 시작 (일반적으로 임의의) 시작 인구를 생성합니다.
b) 백 테스트는 모집단의 각 매개 변수 집합에 대해 AmiBroker가 수행합니다.
c) 백 테스트의 결과는 알고리즘의 논리에 따라 평가됩니다.
새로운 인구는 결과의 진화에 기초하여 생성되며,
d) 새로운 최상의 것이 발견되면 - 그것을 저장하고 기준을 충족시킬 때까지 b) 단계로 진행하십시오.
정지 기준의 예로는 다음을들 수 있습니다.
a) 지정된 최대 반복에 도달.
b) 마지막 X 세대의 최상의 객관적인 값의 범위가 0 인 경우 중지합니다.
c) 주축 방향으로 0.1 표준 편차 벡터를 더하면 목표 값의 값이 변하지 않는다.
AmiBroker에서 스마트 (비 한정적인) 옵티 마이저를 사용하려면 OptimizerSetEngine 함수를 사용하여 AFL 수식에 사용할 옵티 마이저 엔진을 지정해야합니다.
이 함수는 이름으로 정의 된 외부 최적화 엔진을 선택합니다. AmiBroker는 현재 Standard Particle Swarm Optimizer ( "spso"), Tribes ( "trib") 및 CMA-ES ( "cmae")의 3 가지 엔진을 포함하고 있습니다 - 중괄호 안에있는 이름은 OptimizerSetEngine 호출에서 사용됩니다.
최적화 엔진을 선택하는 것 외에도 일부 내부 매개 변수를 설정할 수 있습니다. 이렇게하려면 OptimizerSetOption 함수를 사용하십시오.
OptimizerSetOption ( "name", value) 함수.
이 함수는 외부 최적화 엔진에 대한 추가 매개 변수를 설정합니다. 매개 변수는 엔진에 따라 다릅니다.
AmiBroker (SPSO, Trib, CMAE)와 함께 제공되는 세 가지 최적화 도구는 두 개의 매개 변수를 지원합니다 : "실행" (런 횟수) 및 "MaxEval" (단일 실행 당 최대 평가 (테스트)). 각 매개 변수의 동작은 엔진에 따라 다르므로 동일한 값이 사용되는 엔진에 따라 다른 결과가 발생할 수 있습니다.
Runs와 MaxEval의 차이점은 다음과 같습니다. 평가 (또는 테스트)는 단일 백 테스트 (또는 목적 함수 값의 평가)입니다.
RUN은 (최적의 값을 찾는) 알고리즘의 완전한 실행입니다. 보통 많은 테스트 (평가)가 필요합니다.
각각은 새로운 시작 (새로운 초기 랜덤 모집단)으로부터 전체 최적화 프로세스를 간단히 복구합니다.
따라서 각 실행은 다른 로컬 최대 / 분을 찾도록 유도 할 수 있습니다 (글로벌 하나를 찾지 못하면). 따라서 Runs 매개 변수는 후속 알고리즘 실행 횟수를 정의합니다. MaxEval은 단일 실행의 평가 (bactest)의 최대 수입니다.
문제가 상대적으로 간단하고 1000 개의 테스트로 글로벌 최대 값을 찾으면 5x1000은 글로벌 최대 값을 찾게됩니다.
로컬 맥스에 걸릴 확률이 더 적기 때문에 후속 실행은 다른 초기 무작위 채우기부터 시작됩니다.
매개 변수 값을 선택하는 것은 까다로울 수 있습니다. 테스트중인 문제, 복잡성 등에 따라 다릅니다.
확률 론적 인 비 철저한 방법은 테스트의 수가 적 으면 테스트의 수와 관계없이 전역 최대 / 최소 찾기를 보장하지 않습니다.
철저한 것보다. 가장 쉬운 대답은 완료하는 데 필요한 시간면에서 합리적인만큼 많은 수의 테스트를 지정하는 것입니다.
또 다른 간단한 조언은 새로운 차원을 추가하면서 테스트의 수를 곱하는 것입니다. 그것은 숫자를 과대 평가하는 결과를 가져올 수 있습니다.
테스트가 필요하지만 꽤 안전합니다. 선적 된 엔진은 사용이 간편하도록 설계되어 있으므로 "합리적인" 기본값 / 자동 값이 사용되므로 아무 것도 지정하지 않고 최적화를 실행할 수 있습니다 (기본값 허용).
모든 스마트 최적화 방법은 연속 매개 변수 공간과 상대적으로 부드러운 목적 함수에서 가장 잘 작동한다는 것을 이해하는 것이 중요합니다. 매개 변수 공간이 분리 된 경우 진화 알고리즘은 최적 값을 찾는 데 어려움이있을 수 있습니다. 바이너리 (on / off) 매개 변수에 특히 적합합니다. 객관적인 함수 변경 그라디언트를 사용하는 검색 방법에는 적합하지 않습니다 (대부분의 스마트 메서드가 그렇듯이). 거래 시스템에 많은 바이너리 매개 변수가 포함되어 있다면 스마트 옵티 마이저를 직접 사용해서는 안됩니다. 대신 스마트 옵티 마이저를 사용하여 연속 매개 변수를 최적화하고 수동 또는 외부 스크립트를 통해 바이너리 매개 변수를 전환하십시오.
SPSO - 표준 입자 군 최적화.
Standard Particle Swarm Optimizer는 SPSO2007 코드를 기반으로합니다. SPSO2007 코드는 특정 문제에 대해 올바른 매개 변수 (예 : Run, MaxEval)가 제공되면 좋은 결과를 산출해야합니다.
PSO 최적화 프로그램에 대한 올바른 옵션을 선택하는 것은 까다로울 수 있으므로 결과가 사례별로 크게 다를 수 있습니다.
SPSO. dll은 & quot; ADK & quot; 내부에 전체 소스 코드가 포함되어 있습니다. 하위 폴더.
(10000 조합의 검색 공간 내에서 1000 개의 테스트에서 최적 값을 찾음)
구매 = 십자가 (MACD (fa, sl), 0);
매도 = 크로스 (0, MACD (fa, sl));
트라이브 (TRIBES) - 적응 형 매개 변수가없는 입자 군 최적화 도구.
Tribes는 PSO (Partial Swarm Optimization) 비 포괄적 최적화 프로그램의 적응 형 매개 변수없는 버전입니다. 과학적 배경에 대해서는 다음을 참조하십시오 :
이론적으로 일반 PSO보다 더 나은 성능을 발휘해야합니다. 문제의 해결을 위해 웜 크기와 알고리즘 전략을 자동으로 조정할 수 있기 때문입니다.
연습을 통해 성능이 PSO와 매우 유사하다는 것을 알 수 있습니다.
Tribes. DLL 플러그인은 & quot; 부족 - D & quot; (즉, 무차 원) 변이체이다. Maurice Clerc의 clerc. maurice. free. fr/pso/Tribes/TRIBES-D. zip을 기반으로합니다. 작성자의 허가를 받아 사용 된 원본 소스 코드.
Tribes. DLL에는 전체 소스 코드가 들어 있습니다 ( "ADK"폴더 내부)
"MaxEval" - 실행 당 최대 평가 수 (백 테스트) (기본값 = 1000).
기본 1000은 2 또는 최대 3 차원에 적합합니다.
& quot; 실행 & quot; - 실행 횟수 (재시작). (기본값 = 5)
실행 횟수는 기본값 인 5로 둘 수 있습니다.
기본적으로 실행 횟수 (또는 다시 시작 횟수)는 5로 설정됩니다.
Tribes Optimizer를 사용하려면 코드에 한 줄만 추가하면됩니다.
OptimizerSetOption ( "MaxEval", 5000); // 최대 5,000 개의 평가
CMA-ES - 공분산 매트릭스 적응 진화 전략 최적화 프로그램.
CMA-ES (공변량 행렬 적응 진화 전략)는 고급 비 최적화 알고리즘입니다.
과학적 배경에 대해서는 다음을 참조하십시오 :
과학적 벤치 마크에 따르면 9 가지 다른 인기있는 진화 전략 (예 : PSO, 유전 및 차등 진화)보다 성능이 우수합니다.
CMAE. DLL 플러그인은 & quot; 전역 & quot; 인구 증가와 함께 몇 가지 재시작 검색의 변형.
CMAE. DLL은 전체 소스 코드 ( "ADK"폴더 내부)와 함께 제공됩니다.
기본적으로 실행 횟수 (또는 다시 시작 횟수)는 5로 설정됩니다.
기본 재시작 횟수를 그대로 두는 것이 좋습니다.
OptimizerSetOption ( "Runs", N) 호출을 사용하여 변경할 수 있습니다. 여기서 N은 1..10 범위에 있어야합니다.
가능하면 10 회 이상의 실행을 지정하지 않는 것이 좋습니다.
각 실행은 이전 실행 인구의 크기가 TWICE이므로 기하 급수적으로 커집니다.
따라서 10 회 실행하면 첫 번째 실행보다 인구 2 ^ 10 (1024 배) 증가합니다.
다른 파라미터 "MaxEval"이있다. 기본값은 0입니다. 즉, 플러그인이 자동으로 MaxEval을 계산합니다. 기본적으로 잘 작동하므로 MaxEval을 직접 정의하지 않는 것이 좋습니다.
이 알고리즘은 필요한 평가 횟수를 최소화 할 수있을만큼 똑똑하며 솔루션 포인트에 매우 빠르게 수렴하므로 종종 다른 전략보다 솔루션을 더 빨리 찾습니다.
솔루션이 발견되면 플러그인이 일부 평가 단계를 건너 뛰는 것이 일반적이므로 최적화 진행률 막대가 일부 지점에서 매우 빠르게 움직일 수 있다는 사실에 놀라지 말아야합니다. 또한 플러그인은 솔루션을 찾는 데 필요한 경우 초기 예상 값보다 단계 수를 늘릴 수 있습니다. 그 적응 성질로 인해, "추정 된 남은 시간" 및 / 또는 "단계의 수" 진행 대화 상자에 의해 디스플레이 된 "가장 좋은 추측은 단지 시간" 최적화 과정 중에 다를 수 있습니다.
CMA-ES 옵티 마이저를 사용하려면 코드에 한 줄만 추가하면됩니다.
그러면 대부분의 경우 기본 설정으로 최적화가 실행됩니다.
많은 연속 공간 - 공간 탐색 알고리즘의 경우에서와 같이, "단계"를 감소시키는 것이 주목되어야한다. Optimize () 함수 호출의 매개 변수는 최적화 시간에 큰 영향을주지 않습니다. 문제가되는 유일한 것은 문제 "치수", 즉 상이한 파라미터의 수 (최적화 함수 호출의 수)이다. "단계들"의 수는 " 매개 변수 당 최적화 시간에 영향을주지 않고 설정할 수 있으므로 원하는 최상의 해상도를 사용하십시오. 이론적으로 알고리즘은 많아야 900 * (N + 3) * (N + 3) 백 테스트에서 솔루션을 찾을 수 있어야합니다. 차원입니다. 실제로 그것은 훨씬 빠르게 수렴합니다. 예를 들어, 500-900 CMA-ES 단계에서 3 (N = 3) 차원 매개 변수 공간 (예 : 100 * 100 * 100 = 1 백만 철저한 단계)의 솔루션을 찾을 수 있습니다.
멀티 스레드 개별 최적화.
다중 심볼 멀티 스레딩 외에도 AmiBroker 5.70부터 멀티 스레드 단일 심볼 최적화를 수행 할 수 있습니다. 이 기능에 액세스하려면 & quot; 최적화 & quot; 옆의 드롭 다운 화살표를 클릭하십시오. 버튼을 클릭하고 & quot; 개별 최적화 "를 선택하십시오.
& quot; 개별 최적화 & quot; 단일 심볼 최적화를 수행하기 위해 사용 가능한 모든 프로세서 코어를 사용하므로 일반 최적화보다 훨씬 빠릅니다.
1. 사용자 정의 백 테스터는 지원되지 않습니다 (아직).
2. 스마트 최적화 엔진은 지원되지 않습니다. 소극적 최적화 만 작동합니다.
결국 AmiBroker가 변경되어 사용자 정의 백 테스터가 OLE를 더 이상 사용하지 않을 때 제한 (1)을 제거 할 수 있습니다. 그러나 (2) 아마 오래 머무를 것입니다.

사용자 기술 자료.
2007 년 12 월 24 일.
고주파 자동화 거래 (HFAT); 2 부.
대화 형 중개인의 실시간 볼륨 데이터.
가격 데이터와 마찬가지로 볼륨 데이터는 지연 및 BF (Backfill) 수정의 영향을받습니다. 또한 IB (Interactive Brokers)는 백 테스팅과 실제 거래 간의 주요 성능 차이를 일으킬 수있는 방식으로 볼륨 데이터를보고합니다.
이 게시물은 비교를 위해 RT 및 BF 데이터를 수집하는 간단한 절차를 간략하게 설명합니다. 차이점을 설명하거나 통계 분석을 수행하기위한 노력은하지 않습니다. 여기에 표현 된 견해는 개인적인 경험에 근거하거나 일화 일 수 있습니다. 실시간 거래에서 일어나는 모든 일이 설명하기 쉽지는 않습니다. 기술적 인 통찰력이나 부정확 한 내용이있을 경우 언제나 그렇듯이 향후 독자를 위해 의견을 말하십시오.
예상대로 IB RT 볼륨 데이터에는 백필 중에 수정되는 일반적인 불량 틱 및 지연이 포함됩니다. 그러나 이것은 RT 트레이더에게 매우 중요합니다. IB는 약 30 초 간격으로 라이브 볼륨을 조정합니다. 이는 RT 거래 중에 IB가보고하는 양이 시장 활동을 정확하게 반영하지 않는다는 것을 의미합니다. 이는 볼륨 데이터가 일반적인 스냅 샷 지연 (가격 데이터의 경우 약 300 밀리 초) 대신 최대 30 초까지 지연 될 수 있음을 의미합니다. 백필을 실시간 볼륨과 비교할 때, 실시간 주기적 볼륨 조정은 백필 중에 개별 스냅 샷 전체에 재분배되는 것처럼 보입니다. 이 게시물은 귀하가 자신의 데이터 분석을 수행하도록 돕기위한 것입니다. 아래에 요약 된 방법은 시작하기위한 것입니다.
실시간 데이터를 수집하고 저장하려면 : 5 초 간격으로 새 데이터베이스를 만듭니다. 데이터베이스에 이름을 지정할 때 원시 데이터에 "RD"를 포함시킵니다. 데이터베이스 설정에서 대화 형 브로커 플러그인을 선택하십시오. 고용량 주식 (예 : AAPL)을 선택하십시오 (이 게시물에서 사용됨). TWS (Trader Work Station)에 연결하여 Paper Trading 계정에 로그인하십시오. eDemo 계정을 사용하지 마십시오. 한 시간 분량의 실시간 데이터를 수집하십시오.
TWS에 연결할 때 가장 먼저 일어날 일은 AmiBroker가 대략 2000 바의 5 초 데이터를 백필로 채우는 것입니다. 이는 예방할 수 없으므로 백필이 끝나고 원시 데이터 수집이 시작되는 시간을주의해야합니다. 가장 간단한 방법은 차트에 세로선을 배치하고 "실시간 데이터 시작"으로 레이블을 지정하는 것입니다.
데이터베이스를 저장하려면 : IB 플러그인을 연결 해제하십시오 (차트 오른쪽 하단의 플러그인 메뉴 참조). 데이터베이스 설정을 열고 데이터베이스를 로컬로 설정하십시오. 데이터 수집이 중지 된 위치를 나타내는 다른 수직선을 배치하십시오. 파일 메뉴로 이동하여 데이터베이스를 저장하십시오.
데이터베이스 설정 - & gt; 데이터 소스 - & gt; 저장하기 전에 지역. 이 작업을 수행하지 않으면 데이터베이스가 다음 시작시 백필로 처리되며 이로 인해 RT 데이터 샘플이 손상 될 수 있습니다.
다음 단계는 이전에 수집 된 실시간 샘플과 겹치는 BF 데이터의 샘플을 수집하는 것입니다. 이렇게하려면 다른 데이터베이스를 만들어야합니다. IB는 5 초 데이터 만 약 2,000 개의 바를 백필로 채 웁니다. 따라서 원시 데이터를 수집 한 후 가능한 한 빨리이 작업을 수행해야합니다. 그렇지 않으면 수집 기간이 겹치지 않아 두 데이터 유형을 비교할 수 없습니다. 이 절차는 데이터베이스 이름에 "RD"대신 "BF"(백필 데이터 용)를 포함하려는 것을 제외하고는 위와 동일합니다.
두 데이터베이스를 시각적으로 비교하기 위해 AmiBroker의 두 인스턴스를 열고 하나의 RT 데이터베이스를로드하고 다른 인스턴스의 BF 데이터베이스를로드 할 수 있습니다. 그런 다음 두 데이터베이스를 동시에 표시하고 각 차트를 시각적으로 비교할 수 있습니다. 아래의 캡처와 같이 가격 차트와 볼륨 차트를 별도의 창에 표시 할 수 있습니다.
아래 코드를 사용하여 가격 차트를 검사 할 수 있습니다.
그리고이 코드는 볼륨 차트를 검사합니다.
위의 수식에는 테스트하려는 매개 변수에 대한 기본 차트와 누적 값 (빨간색 영역)이 표시됩니다. 가격 차트에서 고 - 저 범위 (H-L)가 합산되며 볼륨 차트에서 일반 볼륨이 합산됩니다. 합계는 커서가 선택된 막대로 시작됩니다. 이 기능은 데이터 차이점을 시각적으로 나타 내기 위해 제공됩니다. 다른 의미는 없습니다.
아래 차트는 위의 방법을 사용하여 생성되었으므로 두 가지 유형의 데이터 간의 차이가 빠르게 나타납니다. 왜 이런 차이가 발생하는지 설명하는 것은 전문적인 독자에게 달려 있습니다 (단서가 없기 때문에 !!).
그림 1 & # 8211; 백필 데이터.
그림 2 & # 8211; 실시간 수집 데이터.
다음 볼륨 표시기를 사용하여 RT 볼륨주기를보다 명확하게 표시 할 수 있습니다.
이 코드는 아래의 두 차트를 작성했습니다. 간단한 스파이크 필터 (코드의 VSpike 정의 참조)를 사용하여 볼륨 스파이크를 식별하고 검은 색 배경으로 눈에 띄게 만듭니다. 이러한 볼륨 스파이크는 백업 된 데이터에 나타나지 않기 때문에 실제 시장 활동을 반영하지 못한다고 가정 할 수 있습니다. 히스토그램 막대의 맨 위에있는 세 개의 숫자는 위에서 아래로, Volume / 100, 마지막 볼륨 스파이크 이후의 막대 수 및 데이터 타임 스탬프에서 파생 된 Second count를 표시합니다.
그림 3 - 실시간 수집 볼륨 데이터.
백필 데이터에 코드를 적용하면 아래 차트가 생성됩니다. 스파이크 사이의 낮은 볼륨 기간 중 많은 부분이 채워 졌음을 알 수 있습니다 (볼륨 스파이크가 소급하여 배포 된 것처럼 보임) 더 이상 볼륨주기가 보이지 않습니다.
그림 4 & # 8211; 백필 된 볼륨 데이터.
다른 데이터베이스의 데이터 비교.
하나의 차트에서 여러 데이터베이스의 데이터를 비교할 수 있습니다. 두 개의 데이터 배열을 오버레이하면 차이가 즉시 나타나고보다 정교한 분석을 수행 할 것을 제안합니다. 아래 코드는 그 자체로 실행되거나 다른 프로그램에 추가 될 수 있습니다. 이 경우 볼륨 비교를 위해 코딩됩니다. 그러나 가격, 표시기 또는 다른 배열을 비교하기 위해 쉽게 수정할 수 있습니다. SetBarsRequired () 문은 데이터 정렬에 필요합니다. RT 및 BF 차트와 복합 작성에 동일한 시간대를 사용해야합니다. 이 게시물의 모든 테스트는 5 초 동안 수행되었습니다.
BF를 RT 볼륨 배열과 비교하려면 먼저 BF 볼륨의 합성물을 만들고 이것을 이것을 위해 RT 데이터베이스에 복사하십시오. 절차는 다음과 같습니다. BF 데이터 샘플을 포함하는 데이터베이스를로드하십시오. 데이터를 표시하고 Param 창을 엽니 다.
정적 변수 이름으로 BackFillDataSample을 선택하십시오. 만들기를 클릭하십시오. Amibroker 메뉴 바에서보기 - & gt; 모두 새로 고침하십시오. 표시기 창에서 오버레이 합성을 YES로 설정하십시오. 복합 데이터는 볼륨 차트에 겹쳐진 노란색 계단으로 표시되어야합니다. AmiBroker를 닫으십시오. Windows 탐색을 사용하여 BF 데이터베이스를 찾고 "_"폴더에서 BF 용 합성 파일을 복사하여 RT 데이터베이스의 "_"폴더에 붙여 넣으십시오. RT 데이터베이스에서 Broker. Master 파일을 삭제하십시오. 이 파일은 다음 시작시 다시 작성됩니다. 이 단계는 새 복합 파일을 데이터베이스 색인에 포함시키는 데 필요합니다. AmiBroker를 시작하고 RT 데이터베이스를로드하십시오. 함께 작업 한 RT 볼륨 차트를 표시하십시오. 위의 캡처에 표시된대로 매개 변수를 설정하면 RT 볼륨 히스토그램에 겹쳐진 BF 볼륨의 황색 계단이 표시됩니다.
이 시점에서 BF 볼륨이 RT 수집 볼륨과 다른지 확인하기 위해 앞뒤로 스크롤 할 수 있습니다. CREATE를 클릭하지 마십시오. 그렇지 않으면 BF 합성을 덮어 씁니다. 아래 차트는 귀하의 차트가 어떻게 보이는지 보여줍니다.
그림 5 & # 8211; BF 볼륨 히스토그램에서 BF 합성 (노란색).
위의 그림 5는 복합 재료로 덮힌 백필 볼륨 (예 : RT 수집 전 백필 기간)을 보여줍니다. 합성물은이 BF 데이터를 복사했기 때문에 완벽하게 일치합니다.
그림 6 & # 8211; RT에서 BF Composite (노란색)는 볼륨 히스토그램을 수집했습니다.
위의 그림 6은 합성 된 (백필 볼륨)이 실시간 수집 볼륨 (히스토그램)에 겹쳐지는 기간입니다. 두 가지 유형의 데이터의 차이점에 유의하십시오.
거래 시스템을 개발하는 것은 기초에 대해 배우는 것으로 시작해야합니다. 지연 및 나쁜 데이터 품질은 개발에 소요 된 시간에 상관없이 모든 HFAT 거래 시스템을 죽일 수 있습니다. 이해해야 할 가장 좋은 방법은이 시리즈에 포함 된 것과 같은 몇 가지 작은 프로그램을 작성하는 것입니다.
결론.
이전 논의에서, HFAT 거래 시스템을 개발하는 것은 당신이 생각하는 것처럼 쉽지 않을 수 있음이 분명해졌습니다. 정보를 검색하면 실질적인 정보에 대한 링크가 거의 공개되지 않습니다. 당신은 함정을 발견하기 위해 대부분 혼자있을 것입니다. 귀하의 종이 트레이딩 계좌의 실제 데이터로 개발하는 것은 백필 데이터를 사용하는 것보다 낫습니다. 그러나 IB가보고 가격 및 거래량에 따라 종이 거래를 수행 할 가능성이 높으므로 종이 거래 결과가 실제 거래 결과와 일치하지 않을 수 있습니다. 다양한 문제를 정확히 알고 있지 않으면 시스템을 개발하여 5 초 IB 데이터로 HFAT 거래 시스템을 시도하고 개발하는 것은 쓸모없는 것처럼 보일 수 있습니다. 고유 한 실시간 볼륨 패턴은 실제 거래 계정에서 수집 한 데이터에서도 발생했습니다.
모든 출처의 데이터에는 고유 한 문제가 있으며 개발에 많은 시간을 보내기 전에 RT 데이터를 알기 위해 몇 가지 기본 테스트를 수행하는 것이 좋습니다.
IB 스냅 샷 및 데이터 압축 방법은 위의 설명과 관련이 있습니다. 사용할 수있는 세부 정보가 많지 않더라도이 항목에 대한 자세한 내용을 보려면 다음 스레드를 읽는 것이 좋습니다.
알 베노 사 편집.
HFAT (High-Frequency Automated Trading)에 관한 의견; 2 부.
2007 년 11 월 28 일.
고주파 자동화 거래 (HFAT); 1 부.
백필 및 실시간 데이터 문제.
HFAT (High Frequency Automated Trading)에 대해 잘 모르는 경우 Google에 알려주십시오. 이 게시물은 HFAT에 주식을 투자 할 때 발생할 수있는 몇 가지 문제점을 강조합니다. 여기에 표현 된 견해는 개인적인 경험에 근거하거나 일화 일 수 있습니다. 실시간 거래에서 일어나는 모든 일이 설명하기 쉽지는 않습니다. 기술적 통찰력이 있고 부정확 한 내용을 발견하면 향후 독자를 위해 의견을 말하십시오.
고주파 거래 시스템을 설계하고 구현하는 것은 상인의 ​​관점에서 볼 때 궁극적 인 경험 일 것입니다. 몇 초마다 실행되는 거래를보고 들으려면 수익을 압도하는 것이 어떤 상인에게도 전례없는 최고가되어야합니다.
캐치는 실제 현금으로 작동하는 HFAT 시스템을 설계하는 것이 로컬 데이터를 사용하여 설계하는 것과 매우 다릅니다. 시간 프레임이 작을수록 작은 데이터 불일치의 영향이 커집니다. 분 단위 시간대에서 HFAT 시스템은 실시간 원시 시장 데이터보다 로컬 데이터와 매우 다르게 수행 될 수 있습니다.
전형적인 문제는 실시간 라이브 마켓 데이터가 최대 수백 밀리 초까지 지연되고 따옴표가 순서없이 도착할 수 있다는 것입니다. 거래가 이루어진 후 차트에 표시되는 내용이 여러 번 인용 될 수 있습니다. 이 결함 데이터는 거래 시스템이 거래하는 것이며 작동하도록 설계되어야합니다. The charts you see in AmiBroker are mostly backfilled and/or updated after trading hours. At the end of a trading day, you will have data in your database that have a mixture of backfilled data (time and data errors have been corrected) and raw data (flawed) that were collected during the current day’s trading session. You may also have several lengthy data gaps that were introduced when you shut down the system and/or you lost your data feed.
While the procedure may vary for different data providers, quotes that are received in real time will lag in time. Since bar periods during live data collection are based on your computer clock, quotes may end up in the next bar due to their delayed arrival. The data used to backfill your database come from a different data server and will be time stamped. This allows AmiBroker to correct the position of quotes that were received out of sequence. This process removes the real time delays that were present when the data was received.
Since there are no delays with backfilled data, your backfilled data look ahead by several hundred milliseconds with respect to the data you will eventually be trading.
It is not unusual to develop a system with 5-second backfilled data (where all bad ticks and time-stamp errors have been corrected by the data provider) and obtain Holy Grail performance only to find out that when traded with real-time streaming data (where the data is delayed, contains bad ticks and time-stamp errors), the system is a total failure. The following charts illustrate this problem. The data to the left of the red line is backfilled and the data to the right of the Red line is data collected in real time. White is the equity.
You will not be able to visually judge whether data are backfilled or raw. The differences will only show up by running a trading system on the data; your trading system may be the only way to distinguish between backfilled and raw data . The chart below shows a close up of the data change.
Backfilling the above database and performing another Backtest over the same period produces a very different equity:
There is no guarantee that a system developed on one type of data will perform equally well with the other. When you first encounter a major equity drawdown, you may assume that this was just “a bad day”; after all, all trading systems have them. You may have developed and backtested your system over thousands of trades, covering a period of six months or more. You have been a good student and have used all the recommended methods to validate your trading system. You have tested in - and out-of-sample, applied intelligent optimizations, used Walk-Forward testing, performed Monte-Carlo analysis, and the list goes on. After being so thorough, how could you go wrong? You are ready to trade real money tomorrow and make your first 50% in one day!
The point is that all this effort is wasted time if the data used during development aren’t 100% identical to what you will be trading with .
The best way to develop an HFAT system is to use real live market data. The earlier you change from local or edemo data to real data, the more time you will save, and the more disappointments you will be spared. An HFAT system can never be completed off line, with a local database, or with simulated edemo Data. Its design must always include a significant paper trading and real-money phase.
Another problem when trading your IB paper-trading (simulated) account is that the user does not know the rules Interactive Brokers uses to decide whether an order should be executed or not. These execution criteria may change without warning. This imposes an artificial order to your executions that is unreal; the simulated market conditions will be different from those encountered in real trading. You may well develop a trading system that exploits IB’s way of processing to give you unreal performance, but such a system would fail in real trading.
Also, your paper-trades are not seen by, and cannot influence, the market. When trading real money your orders could be setting a new High or a Low, or if you are trading large sums, you could draw the price up or down. This means that even if your system performs extremely well in simulated trading, this is no guarantee that your system will perform well trading real money.
Using your simulated account to validate your system should never be your final validation before trading for profits; you should always include a real-money evaluation phase in your development plan. Your first real trades should never be to make money; they should be planned to validate your system under varied conditions.
Market behavior is very complex; be prepared for the unexpected and never skip a development step because something works extremely well. For example you might be testing your system using your IB simulated paper-trading account and see your profits skyrocket too fast to follow, perhaps having 90% winners and RARs that are out of this world. When this happens, it is extremely exciting and fun to watch; it is a rare experience that must be appreciated. It suggests that Holy-Grails are possible. But are they? Such favorable trading conditions may last for a few hundred trades, a few hours, or perhaps a few days. This can happen when technical conditions and market behavior are all just perfect for your system. Some unknown factor just made everything work perfectly. When you experience this, you’ll be analyzing your charts, trading log, execution report, etc. for weeks to follow. The fact is that it may never happen again, and you may never know what really happened.
Order and Position Status.
IB Position size reporting may be erratic, is always delayed, and may include transient information. If you are trading fast and you use the IB Position Size to determine your next action, this will be a problem. This is especially the case with reversal systems where Covers may be processed before the Buys, and there may be many partial fills. For example, if you are reversing 100 shares, going alternatively Long and Short, you might read position sizes of 0, 100, 200, and even 300 shares. Do not base your system’s action solely on a single reading of the position size; your protective mechanisms will shut down your system many times a day. If a position is not what it is supposed to be on 5 consecutive queries (at quote interval), you may want to close all positions, suspend operation and continue later, or shut down the system and retry later.
Reporting of order status appears more reliable and stable. Usually it seems unnecessary to repeat Order Status queries.
Not addressed in this post is the matter of Snapshots however it is extremely important for real-time traders to understand how IB compresses and transmits its data. This topic has been discussed on several forums, for more information on IB data in general please read the following threads:
The IB Maximum Message Rate.
IB has a limit to the maximum rate of messages (order related) you can transmit per second. The rate of queries is not limited. The current limit is 50 messages per second. If you exceed this rate, IB will produce an error code, and if you continue to exceed the message rate, IB will suspend your connection. This, of course, should be prevented at all cost. The message rates are documented here. How to introduce real-time delays measuring in milliseconds is documented in the post on High Precision Interval and Delay Timing.
Internet Delays.
Order and Position status is subject to a 50-400 milliseconds Internet delay. This delay will vary with your location and type of Internet connection to IB. You can test this delay by pinging the IB server. To do this type ping gw1.ibllc on command in the Start->Run windows (for Windows XP), and click the run button. A window, as shown below, will appear and show you the delays for three consecutive queries (pings) to IB:
If you encounter excessive delays or cannot connect at all, you can get more details about how your connection is routed by running tracert gw1.ibllc in the same manner. You may want to browse the Technical FAQ at IB for related items.
알 베노 사 편집.
August 18, 2007.
Gap-Trading demo, Session Timing Example.
This post shows how to add intraday session timing to the Real-Time Gap-Trading (RTGT) system developed in the previous post. However, before tackling session timing, there are a few things you should be aware about:
Time-Synchronization.
In real-time trading there are many functions that are timed with reference to your system’s clock. It is therefore imperative that you always synchronize your computer clock with an Internet timeserver before each trading session.
Tools -> Preferences -> Intraday settings.
Data Timestamps can be aligned to either the start or the end of the base period. The code developed here uses time of FIRST tick inside bar , i. e., the data timestamp returns the time at the start of the bar. This is when the first quote for the new period arrives and defines the Open for the new bar. Click Tools -> Preferences -> Intraday to set this option:
Backtesting and Bar-Replay.
During backtesting the timing resolution will be equal to the periodicity set in AA Settings. If you are comparing Backtester signals with the signals displayed on your chart, you must make sure that the AA and Chart use the same periodicity.
During Bar Replay the timing resolution will be equal to the greater of the base interval of your database or the Step Interval selected in the Bar-Replay window.
During Backtesting and Bar-Replay, AmiBroker will refer to the timestamp to know how prices change over time. Hence, you will have no choice but to time events, such as session timing, with reference to the data timestamp.
라이브 거래.
When trading from an Indicator, the data timestamp is rounded to the selected chart-periodicity, i. e., if you display a 1-minute chart, the timing resolution will be one minute. This means you cannot implement delays based in seconds using the data timestamps of a minute database. This is why most functions in a real-time trading system use the computer clock as reference.
You can, with caution, use either the data timestamp or the system’s clock to control your session. However, since the data timestamp is dependent on the arrival of new quotes (ignoring data padding), using data timestamp could be unreliable. If you want higher timing resolution, you could create a 5-second database. However, this means working with slow backfills and slow AFL executions, due to lengthy data histories. To keep things simple, we will use a one-minute database.
Session Timing.
When you are developing real-time trading systems, it is often handy, even essential sometimes, to develop several code versions. Typically, these might include:
1) A version for Backtesting and Bar-Reply. This version would use the TimeNum function for timing.
2) A Real-Time trading version. This version would use the system clock (Now()) for timing and would be highly optimized for AFL execution speed.
3) A DebugView version. This is a useful intermediate development stage that lets you run your system in real-time without any TWS interfacing; it logs trades to DebugView instead of sending them to the TWS.
ParamTime() input statements are used to set the start - and end-time of the trading session. The code below is only intended for preliminary system evaluation using the Backtester: hence, is uses time-numbers for session timing.
The StartOfSession and EndOfSession variables are triggers (they last only one bar). They are used to initialize processes at the start of the session and clean up processes at the end of the session. The InSessionTime variable is True during trading and is used to control processes that must be turned On/Off depending on whether you are trading or not. These processes will be covered in future posts.
A TimeFrame Parameter has been added to help visualize how the system works in different timeframes. To see the equity for different timeframes, just drag the slider to see the system response to any timeframe from 1 minute to 1 hour. Having added Session Timing you can now explore whether this system is more profitable during certain hours of the trading day. I suggest you perform an individual backtest on you favorite watchlist; you may be surprised to find that with some systems there is no need to trade all day. More…
For debugging purposes, you can turn On/Off a colored ribbon to display the Start - (Green), End - (Red) and In-Session (Yellow) variables.
For convenience the code below includes all previously developed parts. Just copy to an Indicator formula window, and click Apply.
Comments Off on Gap-Trading demo, Session Timing Example.
August 15, 2007.
Real-Time Gap-Trading Demo, Basics (v3)
This system was intended to provide signals to demo trade automation. However, its signals are not that frequent and it proved to be quite boring to automate it. The code is left here but I plan to use another system to demo trade automation. You may also note that I separated Real-Time System Design from System Automation. This was done to allow categories to evolve independent from each other.
To develop trade-automation code we need a demo system to generate signals and to test TWS interfacing. To be able to continue this series and not waste time looking for a superb system, I’ll use the following very simple trading rules:
Buy at the Open of the current bar if it falls below the previous Low.
Sell at the Close when the current Low falls below the previous Low.
Short at the Open when the Open exceeds the previous High.
Cover at the Close when the current High exceeds the previous High.
In AFL this looks like this:
The above code is a variation of The Full Gap-Trading system. You can read more about this type of system on the Stockcharts site and many other Internet sites.
This system will produce trades in all timeframes, trade frequently, and trade both long and short. Running this system in the 1-15 minute timeframe will give us lots of action and make it easier to develop and debug the Trade-Automation (TA) code. An AT trading system designed around a system that gives only a few signals a day will take forever to debug. Mechanical performance is the first objective.
For now we assume that we can enter at the bar’s Open price. Note that I exit at the Close of the bar because, in the AmiBroker database, this is the next price that is available. At this stage this system is designed to stimulate trade-automation code and not to make you rich; DO NOT TRADE IT. Order types and/or strategies will be decided on later. Trade-Delays are set to zero because they are better handled in the code. The Equity(1) statement is used to remove redundant signals. The indicator should display trades as follows:
알 베노 사 편집.
August 12, 2007.
Designing a Tradable System – Spikes.
The phenomenon that is the basis of many trading systems is the observation and trading of an exceptional price movement followed by a pullback.
An extreme example of the pullback phenomenon would be a Spike as shown in the chart below. Because the price change is so extreme, the pullback or correction appears instantaneous. There is no clear market response, i. e., traders at large are not inclined to take the price change seriously.
The problem is that inadvertently you can easily write code that trades these spikes. Only when you start trading such a system will you discover that your orders are not filled because the volume just isn’t there. This is a common reason why backtested and real results may sometimes differ substantially. You may have designed a system that is completely rational, backtests perfectly, and stands up to the most detailed technical scrutiny, only to find out that in real trading it fails completely.
You might think that by increasing the timeframe, for example to 15-minute or even daily, you can minimize this problem. However, while doing this may make the spikes less prominent, the tradability will not improve. Consider the spike in the 15-minute chart below:
Adding a few percent bands makes this look like a real trading opportunity. It looks so easy! However, the Low of the bar is still created by a single trade and the chance to get your order filled would still be minimal. Designing trading systems around minimal-volume price changes is one of the easiest traps for a real-time system developer to fall into. When designing an intraday trading system you should design your code to minimize the divergence of the backtester with respect to real-trading results. You can do this by working in the smallest time frame possible. Even when trading at hourly intervals you should write your code in the minute (or even Tick) timeframe.
There are a number of ways in which to do this. Take a look at the 10:30 AM spike in the 15-minute chart below and consider how you would determine its tradability:
The fact is that there is no way to tell whether the 10:30 AM High is tradable. However, expanding the chart to the 1-minute timeframe, as shown below, lets you clearly see a gradual reversal pattern. This means your order could probably have been filled somewhere near the top of the 15-minute spike shown earlier.
Running your Backtester in the 1-minute timeframe and looking for one-bar confirmations may drop your backtester performance, but your results would have been closer to that which can be obtained in real trading. In this case you would have separate Backtester and Trading code versions for your system; the Backtester code would include signal confirmation while your Trading code would not.
알 베노 사 편집.
Comments Off on Designing a Tradable System – Spikes.
July 21, 2007.
System-Design Pitfalls.
When you are designing a real-time trading system, many things can go wrong. This post is intended to alert you to some of the potential pitfalls. However, that is all it can do. Only experience can teach you how to prevent them. Be aware that even the most experienced designers will make some of these mistakes repeatedly.
Since documenting all potential pitfalls with coding examples would consume too much time and space, they are, for now, only briefly commented on. Most of them will trigger a user response of “Oh yeah, that happened to me!”. If you need a more detailed explanation you can post questions in a comment to this post.
No rules exist to prove that a trading system is free from coding or logical errors. However, two indicators are fairly reliable in suggesting you may have a problem:
1) Your profits are simply too good to be true. In this case you have no choice but to work through the code line by line, trying to find lines of code that look into the future. If that doesn’t reveal any errors, then you would have to inspect the plotted signals and trade list trade by trade.
2) Your system is very profitable trading Long but not Short, or Short buy not Long. When this happens, you may have an error in either the Long or Short parts of your code, and comparing the two sections will often reveal the problem (this only works for reversal systems). However, it could also be that your code is correct but that your trading principle is overly trend sensitive. This would almost certainly get you in trouble when the trend reverses. In this case no other cure exists than to re-think the basic system.
When designing high-frequency trading systems, i. e., those whose trade durations are in minutes, everything changes, and many traditional procedures fall apart. Internet delays, data delays, bad data (spikes), temporary system freezes (Windows sometimes has a mind of its own!), lagging status reports, TWS problems, etc., all become critical issues that will prevent you from obtaining a close match with the Backtester.
Many of these problems will only surface when you start trading real money. Hence, the final stages of developing a trading system should always involve trading real money. Here is where the Interactive Brokers account simulator (paper-trading account) may be an indispensable tool since you can test your system in real time without committing real dollars. But, since the market does not see your trades, even paper-trading results will differ from trading real money. In general, the faster you trade, the greater your real-trading results will deviate from your backtest results. You should also be aware that commissions play a much greater role on performance of high-frequency trading systems because trade profits are smaller.
No matter how you go about it, troubleshooting a complex trading system will almost always be a tedious and boring job that could keep you busy for several days or weeks. If you find that certain problems continue to resurface, they are likely related to your personal development style, and you may be able to write some code that checks for these specific problems. See the Debugging category for some ideas.
The list below, which is not exhaustive, is presented to caution you that many areas can lead to problems. Some are obvious, while others may be expanded on as needed and time allows.
& # 8211; High/Low precedence (contrary to EOD where the Backtester is unable to determine which came first, the entry/exit or the high/low, in realtime there can be no ambiguity in price precedence).
& # 8211; Data Delays (real-time data may be delayed for various reasons and time periods (Internet delays, lack of quotes, packets vs. ticks, etc.).
& # 8211; Low Liquidity (there may be no-volume trading periods).
& # 8211; Data Holes (bars with no trades).
& # 8211; Data Spikes (high spikes without volume may trigger trades).
& # 8211; Data Padding (a bar without data may be padded).
& # 8211; Premature Padding (the last bar may be a padded bar).
& # 8211; Data Accuracy (prices you receive aren’t always accurate).
& # 8211; Random Slippage (you will rarely get the expected price).
& # 8211; Breakout slippage (you will rarely get the Breakout price of your system).
& # 8211; Survivorship Bias (companies that didn’t do well and stopped trading won’t be in your database, i. e., you are working above average stocks).
& # 8211; Lucky Trades (a series of lucky trades may look like good performance).
& # 8211; Parameter Over-Optimizing (optimized parameters are rarely stable over time).
& # 8211; Design Over-Optimizing (frequent testing is like running an optimization and may be leading to false conclusions).
& # 8211; Out–of-Bound Prices (with PriceBoundChecking turned ON, AmiBroker forces the trade price within the High-Low range, this may hide pricing errors).
& # 8211; Price Rounding (prices may be rounded or truncated by the broker).
& # 8211; Wrong Use of >= and = in the same statement, only the first equal condition will ever be seen).
& # 8211; Comparing Floating Point Numbers (calculated values can have many decimal places, either round values or use the AlmostEqual()).
& # 8211; Chart Justification (make sure you are looking at the Last bar!).
& # 8211; System Mortality (no system will work forever).
& # 8211; Sharing Trading Systems (sharing systems with other traders may result in over-trading a system).
& # 8211; Being Duped by a Trend (a rallying ticker may make your system look like the HG (holy grail).
& # 8211; Tricking AmiBroker (AmiBroker has its limits; it is possible to write esoteric code that will produce wrong results).
& # 8211; Order Visibility (placing your order for every trader to see may influence the orders they place).
& # 8211; Making the Market (extreme example: if you place a MKT order during a no-trading period you will change the chart).
& # 8211; Window/Pane Execution Order (when passing variables between panes or windows do not assume that they execute in a fixed order, more).
& # 8211; Trading at the Open (order execution at the start/end of day is different from midday because of volatility and data delays).
& # 8211; IB Data Snap Shots (snapshots are only representative of prices traded).
& # 8211; Trade Delays (make sure you understand your trade delays when backtesting).
& # 8211; EOD and Intraday Gaps (There is no time interval in RT gaps).
& # 8211; Time Zones (make sure your computer and database timezones are properly set).
& # 8211; Very Short Time-Frames (prices jump and are less contiguous).
& # 8211; Setting LMT Prices (consider rounding for faster order executions).
& # 8211; 24-Hour vs. RTH (Regular Trading Hour) Backtesting (extended hours can rarely be traded like RTH due to huge bid/ask spreads and low volume).
& # 8211; Static Variables Naming (use unique names for your static variables).
& # 8211; Incorrect Computer Time (computer time offset from market time can cause real problems).
& # 8211; Look-Ahead Problems (not all look-ahead coding problems are obvious).
& # 8211; Buy/Sell Precedence in a Loop (be aware that AB and custom AFL loops enforce a Buy/Sell priority).
& # 8211; RT Candle Discrepancies (RT Candles may be different from later backfills, especially in the opening print).
& # 8211; Bars Loaded (consider bars-loaded with respect to execution speed and loops).
& # 8211; Signal lifetime (signal strength quickly decays over bars in high frequency trading).
& # 8211; SameBarExits (Sell signals may act as a qualifier for Buy signals).
& # 8211; Designing systems based on High and Low triggers (these may fill in the Backtester but not in real trading). more…
& # 8211; Using the wrong CommissionMode and/or CommissionAmount can make any system look good, or bad…
& # 8211; Using zero TradeDelays is OK if you code the delays in your system’s code, else you may be looking into the future.
알 베노 사 편집.
Comments Off on System-Design Pitfalls.
June 19, 2007.
Introduction to Real-Time System Design.
Developing trading systems is a very personal activity, and opinions vary widely regarding what is the best approach. Most of the solutions presented here were developed by Herman van den Bergen. They may not be compatible with your personal preferences and you are encouraged to explore other alternatives more suited to your own trading style before deciding on a possible solution. To develop a Real-Time Automated Trading (RT/AT) system, you must have a trading system to automate. If you haven’t developed one yet, you may find some ideas in the Research and Exploration or Trading-Systems categories.
Modular design, readability, and simplicity of the system code are desirable to facilitate future maintenance. Posts in this category will progress through the various phases of developing a Real-Time Automated system.
알 베노 사 편집.
Comments Off on Introduction to Real-Time System Design.
최근 게시물.
최근 댓글.
Richard Dale on Data Resources & # 8211; Forex Herman 요청 실시간 주제 여기 Mike B 실시간 요청 주제 여기 Tomasz Janeczko on US-Stocks 데이터베이스 (v2) brian_z on Setup A Custom Database & # 8211; 나스닥
카테고리.
2011 년 10 월 2011 년 1 월 2011 년 7 월 2011 년 7 월 2011 년 4 월 2011 년 2 월 2011 년 2 월 2011 년 2 월 2011 년 1 월 2 월 2009 년 2 월 2008 년 1 월 2008 년 4 월 (1) 2008 년 2 월 (20) 2008 년 1 월 (1) 2008 년 1 월 (1) 2007 년 12 월 (4) 2007 년 10 월 (18) 2007 년 9 월 (17) 2007 년 8 월 (26) 2007 년 6 월 (17) 2007 년 5 월 (8) 2007 년 4 월 (16) 2007 년 1 월 (1)
This site uses WordPress Page generated in 0.298 seconds.

Amibroker Trading System Design – Bangalore Workshop & # 8211; May 2017.
At Premier Inn, Brookfield Main Road, Opp to Shell Petrol Pump, Seetharampalya, Hoodi, Bangalore, Karnataka, India.
Customer Support : 09738383344 / 09535133445 ( 9a. m – 6p. m IST Mon-Fri)
What Will be Covered in the Workshop?
1)The various aspects of trading systems design, how to generate original ideas for systems, statistical approaches to systems and the effective use of indicators.
2)Trading Rules on when to activate and when to discard Trading systems.
3)Single Trading System Vs Portfolio Trading System. 장점과 단점.
4)Trading System Optimization, Guidelines and how frequent to fine tune the system.
5)Which timeframe to trade effectively. What type of Trading system to follow.
6)Discussion on Automating your Trading System, Available Platforms, Cost.
7)How to Build Seasonal and Discrete trading systems.
1)Quick Introduction to Trading System Design, Backtesting and Optimization concepts using Amibroker.
2)What kind of performance you can expect from the trading system. Testing the reality of various trading systems.
3)How to design Intraday Trading Systems or Time Based Trading Systems.
4)How to Validate the Robustness of the Trading Systems.
5)Discretionary Systems Vs Fully Systematic Approach.
6)How to choose the right money management approach.
1)Which timeframe to trade effectively. What type of Trading system to follow.
2)How to Measure the Benchmark of various trading systems.
3)How to Build Portfolio Trading Systems.
4)Discussion on Automating your Trading System, Available Platforms, Costfactors.
5)Discussion on any other systems you want to talks about.
6)Introduction to Marketcalls Trading Studio (collection of custom designed premium indicators) and 1 Year of Complementary Access to Marketcalls Trading Studio.
Participants will receive various USB stick of slides, indicators, test data used during the presentations. The presenters will be providing the codes of some live systems they currently use to trade in order to help explain the various concepts they cover.
Participants will also, of course, get the code of anything developed during the workshop.
1 Year of Complementary Access to Marketcalls Trading Studio.
1 Year of Access to 20 Hours of Amibroker AFL Coding Tutorials.
Special offers from our Event Sponsors & Delicious Lunch.
Basic understanding of the stock markets, futures and options.
A Laptop (Windows) with Amibroker version 5.8 or above Installed.
Who Should Attend this Workshop.
Traders, Analysts, Brokers, College Students , Anyone interested in Investing, DayTrading, Technical Analysis, Trading Strategies, Trading Softwares, Trading System Development, Autotrading enthusiasts.
관련 독서 및 관찰.
Tradezilla – Online Mentorship Program for Traders Tradezilla is India's first ever exclusive and intensive ever online trading mentorship program for budding traders. Event will focus on providing quality information to Traders, […] Divergence 2016 – Traders Annual Web Conference Divergence is India's largest traders web conference and first ever online conference from marketcalls. This year we are focusing on topics like System trading, Amibroker AFL Programming, […] Amibroker AFL 2015 – Bangalore Workshop Photo Gallery Amibroker AFL 2015 - Bangalore Workshop Photo Gallery Amibroker AFL coding – Photo Gallery First of all I personally thank Mr Jagdish Ahuja(ATMA organizer) for providing oppurtunity and organizing this Amibroker AFL coding to make this event successful one. The event is less of […] “Amibroker AFL coding” & # 8211; 26th ATMA Bengaluru Meet This is my first event with ATMA. Will be speaking about Amibroker AFL coding concepts. Probably the first ever group to discuss about Programming concepts and provide live coding […] Coimbatore Amibroker Workshop – Photo Gallery First of all I personally thank Mr Ravi Shengodan (Brokerage Free) AP of Zerodha for organising this workshop neatly and done lots of efforts in the backend to make this event successful […]
Rajandran에 대해서.
라잔 드란 (Rajandran)은 풀 타임 (full time) 상인이자 Marketcalls의 설립자이며, 타이밍 모델, 알 고스, 임의 거래 개념 및 트레이딩 센티멘털 분석을 구축하는 데 큰 관심을 가지고 있습니다. 그는 이제 경험 많은 상인, 전문 상인, 개인 상인에 이르기까지 전 세계 사용자에게 지시합니다.
라잔 드란 (Rajandran)은 첸나이 (Chennai)에서 대학을 다녔으며 전자 및 통신 분야에서 BE를 받았습니다. Rajandran은 Amibroker, Ninjatrader, Esignal, Metastock, Motivewave, Market Analyst (Optuma), Metatrader, Tradingivew, Python과 같은 거래 소프트웨어에 대한 폭 넓은 이해를 가지고 있으며 다양한 방법론을 활용하여 거래자와 투자자의 개별 요구 사항을 이해합니다.
I am interested in backtesting an idea for a rotational momentum strategy and wondered if this is a service that you offer?
yes we do. You can send your requirements to rajandranmarketcalls. in.
I am interested in trading signal in stock an idea for a momentum strategy ,
please reply for malayalam language, i am malayalee from kerala,
회신을 남겨주 답장을 취소하십시오.
미국 정부의 면책 및 CTFC 규칙이 필요함. 4.41.
© 저작권 2015 Marketcalls Financial Services Pvt Ltd & middot; 판권 소유 및 중재; 그리고 우리의 Sitemap & middot; 모든 로고 & amp; 상표는 그들의 각각의 소유자 & middot에 속한다;