아미 브로커 (Amibroker) 차트 옵션 설정
- 자동 분석 설정에서 옵션을 설정합니다.
무역 시스템 도구 상자.
field - 변경할 옵션을 정의하는 문자열입니다. 사용할 수있는 옵션은 다음과 같습니다. & quot; NoDefaultColumns & quot; - True로 설정하면 탐색시 기본 시계 및 날짜 / 시간 열이 없습니다. "InitialEquity" & quot; AllowSameBarExit & quot; "ActivateStopsImmediately" & quot; AllowPositionShrinking & quot; & quot; FuturesMode & quot; "InterestRate" "MaxOpenPositions" - 포트폴리오 백 테스트 / 최적화 "WorstRankHeld"에서의 동시 개방 위치 (거래)의 최대 수 - 회전 거래 모드에서 개최되는 기호의 최하위 순위 (자세한 내용은 EnableRotationalTrading 참조) & quot; MinShares & quot; - 백 스터 / 옵티 마이저에서 포지션을 여는 데 필요한 최소 공유 수. 많은 것을 구입할 수있는 자금이 충분하지 않으면 "MinPosValue"를 입력하지 않아도됩니다. - 백 테스터 / 옵티 마이저에서 포지션을 여는 데 필요한 최소 달러 금액 (4.70.3 이상). 자금이 충분하지 않으면 거래가 입력되지 않습니다. & quot; PriceBoundChecking & quot; - False로 설정하면, buyprice / sellprice / coverprice / shortprice 배열을 검사하여 현재 심볼의 High-Low 범위로 조정합니다. 커미션 모드 -
0 - 포트폴리오 관리자 커미션 테이블을 사용합니다.
1 %의 무역.
CommaAmount - 모드 별 커미션 금액 1..3 AccountMargin (예전의 경우 'MarginRequirement') - 계정 마진 요구 사항 (설정에서와 같이), 100 = 여백 없음 ReverseSignalForcesExit - 역 엔트리 신호 강제 종료 기존 거래액의 (기본값 = True) UsePrevBarEquityForPosSizing - 현재 지분 위치 크기 조정의 비율에 영향을 미칩니다.
거짓 (기본값) : 현재 (일중) 자본을 사용하여 위치 크기 조정,
True는 다음을 의미합니다. 이전 크기를 사용하여 위치 크기 조정 수행 PortfolioReportMode - 역 테이터 보고서 모드 설정 :
1 - 자세한 로그.
3 - 출력 없음 (커스텀 전용) UseCustomBacktestProc - True / False - 커스텀 백 테스트 프로 시저를 켜거나 끌 수 있습니다. EveryBarNullCheck - 배열의 모든 막대에 대해 산술 연산에서 Null을 검사 할 수있게합니다 (기본적으로 OFF입니다. 즉 AmiBroker 배열의 처음과 배열의 끝 부분에 나타나는 null을 검사하고 일단 null이 아닌 값이 감지되면 중간에 더 이상의 구멍 (null)이 없다고 가정합니다. & quot; EveryBarNullCheck & quot; to True로 설정하면 4.74.x 및 이전 버전의 작동 방식 인 모든 bar에 이러한 검사를 확장 할 수 있습니다.
그러나이 옵션을 켜면 엄청난 성능 저하가 발생합니다 (이 옵션이 켜져있을 때 산술 연산이 4 배 더 느리게 수행되기 때문에 실제로 사용하지 않으면 사용하지 마십시오). HoldMinBars - Number - 값> 0으로 설정된 경우 신호 / 정지가 해당 기간에 생성 되더라도 사용자 지정 막대 수가있는 동안 종료를 비활성화합니다. EarlyExitBars - 값> 0으로 설정하면 숫자 - 특별 조기 종료 (사용) 요금을 발생시킵니다 이 기간 동안 거래가 종료 된 경우 요금이 부과됩니다. EarlyExitFee - 조기 퇴출금의 % (백분율) 값을 정의합니다. HoldMinDays - 번호 - 값> 0으로 설정된 경우 - 사용자가 지정한 일 수 해당 기간 동안 신호 / 정류장이 생성됩니다. EarlyExitDays - 값이 0보다 큰 경우 - 거래가 특정 기간 (바가 아님) 동안 종료되면 특별 조기 종료 (상환) 비용이 부과됩니다. DisableRuinStop - TRUE로 설정 됨 내장 됨 ruin stop이 비활성화 됨 보고서 생성 - 백 테스트 보고서 생성을 억제하거나 강제 적용 할 수 있습니다. 허용되는 값 : 0, 1 또는 2입니다.
기본적으로 백 테스트 보고서는 포트폴리오 백 테스트 및 개별 백 테스팅의 경우에만 설정에서 개별보고가 설정되어있는 경우에만 생성됩니다. 최적화를 위해 보고서를 사용할 수 없습니다.
이제 SetOption () 함수를 사용하면 코드 수준에서 백 테스트를위한 보고서 생성을 억제하거나 특정 최적화 단계에서 보고서 생성을 활성화 할 수 있습니다.
SetOption ( "GenerateReport", 0); // 보고서 생성을 억제합니다.
SetOption ( "GenerateReport", 1); // 전체 보고서 생성을 강제 실행합니다.
SetOption ( "GenerateReport", 2); // 보고서 탐색기에서 단일 행으로 볼 수있는 단 한 줄 보고서 (results. rlst 파일)가 생성됩니다. SeparateLongShortRank - True / False.
별도의 장 / 단 순위가 가능 해지면, 백 테스터는 2 개의 별도의 "최상위 등급" 하나는 긴 신호용이고 다른 하나는 짧은 신호용입니다. 이렇게하면 길고 짧은 후보자가 위치 점수가 대칭 적이 지 않더라도 (예 : 긴 후보자가 매우 높은 긍정적 인 점수를 얻었고 짧은 후보자는 소수의 부정적인 점수 만 갖는 경우) 독립적으로 긴 후보자와 짧은 후보자가 있습니다. 이는 절대 점수가 중요하지 않은 기본 모드와 대조됩니다. 따라서 스코어 값이 비대칭 인 경우 한쪽 (길고 짧은)이 순위를 완전히 독점 할 수 있습니다.
SeparateLongShortRank가 활성화 된 경우 백 테스트의 두 번째 단계에서 두 개의 개별 순위 목록이 우선 순위가 가장 높은 순서로 정렬 한 다음 최상위 순위로 정렬 한 다음 두 번째 최상위 순위로 정렬 한 다음 두 번째 최상위 순위로 정렬 한 다음 세 번째 최상위로 정렬하여 최종 신호 목록을 형성하도록 인터리브됩니다. 순위가 3 위, 1 순위가 짧았습니다. (신호가 긴 / 짧은리스트 모두에 존재하는 한, 주어진 종류의 신호가 더 이상 없다면 긴리스트 또는 짧은리스트의 나머지 신호가 추가됩니다)
예 : 입력 신호 (점수) : ESRX = 구매 (60.93), GILD = Short (-47.56), CELG = 구매 (57.68), MRVL = Short (-10.75), ADBE = 구매 (34.75), VRTX = 15.55), SIRI = 구매 (2.79),
신호의 절대 값이 긴 신호의 해당 점수보다 작더라도 짧은 신호는 긴 신호간에 인터리브됩니다. 또한 특정 바에 대한 단 두 개의 짧은 신호 만 있으므로 목록의 나머지 부분은 위치 스코어의 순서로 긴 신호를 보여줍니다.
이 기능은 독립적으로 사용할 수 있지만 MaxOpenLong 및 MaxOpenShort 옵션과 함께 사용해야합니다. MaxOpenLong - 동시에 열 수있는 LONG 위치의 수를 제한합니다. MaxOpenShort - 동시에 열 수있는 SHORT 위치의 수를 제한합니다.
ZERO (기본값) 값은 NO LIMIT을 의미합니다. MaxOpenLong 및 MaxOpenShort가 모두 0으로 설정되거나 전혀 정의되지 않은 경우 백 테스터는 기존 방식대로 작동합니다. 거래 유형에 관계없이 글로벌 제한 액티브 (MaxOpenPositions) 만 있습니다.
이러한 제한은 전역 제한 (MaxOpenPositions)과 관련이 없습니다. 즉, MaxOpenLong + MaxOpenShort가 MaxOpenPositions와 같을 수도 있고 같지 않을 수도 있습니다.
MaxOpenLong + MaxOpenShort가 MaxOpenPositions보다 큰 경우 허용되는 총 위치 수는 MaxOpenPositions를 초과하지 않으며 개별적인 긴 / 짧은 제한도 적용됩니다. 예를 들어, 시스템 MaxOpenLong이 7로 설정되고 maxOpenShort가 7로 설정되고 MaxOpenPositions가 10으로 설정되고 시스템에서 20 개의 신호 (길이가 가장 길고 최상위 11)가 생성되면 7 개의 길고 3 개의 단락이 열립니다.
MaxOpenLong + MaxOpenShort가 MaxOpenPositions보다 작지만 (0보다 큰 경우), 시스템은 (MaxOpenLong + MaxOpenShort) 이상을 열 수 없습니다.
또한 MaxOpenLong 및 MaxOpenShort는 주어진 유형 (long / short)의 열린 포지션 수를 제한합니다. 그들은 랭킹이 이루어지는 방식에 영향을 미치지 않습니다. 나는. 기본적으로 순위는 ABSOLUTE positionscore 값을 사용하여 수행됩니다.
순위 점수가 대칭 적이 지 않으면 한쪽에서 원하는 최고 순위 신호를 얻지 못할 수도 있습니다. 따라서, 회전 균형 ( "시장 중립")의 롱 / 숏 시스템에서 MaxOpenLong 및 MaxOpenShort를 완전히 이용하기 위해서는 긴 신호 및 짧은 신호에 대해 별개의 랭킹을 수행하는 것이 바람직하다.
장 / 단점 순위를 별도로 사용하려면 다음을 수행하십시오.
SetOption ( "SeparateLongShortRank", True); RefreshWhenCompleted - TRUE로 설정하면 View -> Automatic Analysis 작업 후 Refresh All (스캔 / 탐색 / 백 테스트 / 최적화)이 완료됩니다. RequireDeclarations - TRUE로 설정된 경우 AFL 엔진은 수식 별 수식에 항상 변수 선언 (로컬 / 전역 사용)을 요구합니다. ExtraColumnsLocation - 사용자가 백 테스트 / 최적화 중에 추가 된 사용자 지정 열의 위치를 변경할 수 있습니다.
a) 사용자 정의 백 테스터를 사용하여 추가 된 모든 사용자 정의 메트릭.
b) Optimize () 함수를 사용하여 정의 된 모든 최적화 매개 변수.
맞춤 측정 항목과 최적화 매개 변수가 모두있는 경우 맞춤 측정 항목이 먼저 나타나고 최적화 매개 변수가 나타납니다.
이 함수는 사용자가 디폴트 "at the end"를 변경할 수 있도록 제공된다. 맞춤 항목 / 최적화 매개 변수의 위치
해당 맞춤 측정 항목이 표시되고 opt 매개 변수가 나중에 열 1부터 추가됩니다 (마지막 열 기본값과 반대)
이 설정은 & quot; 시각적 & quot; 열 순서가 아니고 실제로 메모리 내 순서 나 내보내기 순서가 아니므로 내 보낸 데이터 파일이나 복사 / 붙여 넣기 형식은 변경되지 않습니다. SettlementDelay - 이 옵션은 판매 대금이 정산되고 새 직위를 여는 데 사용할 수있는 일수 (막대가 아님)를 나타냅니다.
SetOption ( "SettlementDelay", 3); // 그러면 판매 대금은 판매 후 3 일에 거래가 가능합니다.
자세한 추적 & quot; 세부 로그 & quot; 보고서 옵션에 T + 1, T + 2 등의 사용 가능 및 미결 자금이 표시됩니다.
참고 :이 옵션을 사용하는 경우 backtestRegular 대신 backtestRegularRaw를 사용하는 것이 좋습니다. 그렇지 않으면 자금이 즉시 결제되지 않고 처음에는 아니지만 후속 구매 신호에 입력 할 수 있어야하므로 일부 거래가 입력되지 않을 수 있습니다. 이는 바로 backtestRegularRaw 제공합니다.
Note2 : 오래된 백스터 (Equity () 함수)는 결제 지연을 무시합니다. StaticVarAutoSave - 영구적 인 정적 변수의 주기적 자동 저장을 허용합니다 (종료시 저장하는 것 이외에는 항상 수행됩니다).
SetOption ( "StaticVarAutoSave", 60); // 60 초마다 영구 변수 자동 저장 (1 분)
영구 변수는 사용자 개입없이 자동으로 EXIT에 저장되므로 대부분의 경우에 충분해야한다는 것을 이해하는 것이 중요합니다. AmiBroker가 실행 중일 때 자동 저장을 원할 경우이 기능을 사용할 수 있습니다. 실제 디스크 파일에 많은 정적 변수를 작성하는 데는 시간이 걸리고 모든 정적 변수 액세스가 차단되므로 너무 작은 자동 저장 간격을 지정하지 않아야합니다. 매 초마다를 저장하는 것은 나쁜 아이디어입니다. 과부하가 발생할 것입니다. 60 초마다 절약하면됩니다. 간격을 0으로 설정하여 기능을 호출하면 자동 저장이 비활성화됩니다.
SetOption ( "StaticVarAutoSave", 0); MCEnable - 몬테카를로 시뮬레이션을 제어합니다 : 0 - 비활성화, 백 테스트에서 1 활성화, 백 테스트 및 최적화에서 2 활성화 됨 MCRuns - 몬테카를로 시뮬레이션 실행 횟수 (realization) 기본값 1000 MCPosSizeMethod - 몬테카를로 위치 크기 방법 : 0 - MCPosSizeShares - MC 시뮬레이션의 거래 당 주당 MCPosSizeValue - MC 시뮬레이션의 거래 당 달러 가치 MCPosSizePctEquity - MC 시뮬레이션의 거래 당 현재 지분의 백분율 MCChartEquityCurves - true / false (1/0) - 몬테카를로 형평성 차트를 활성화합니다. MCStrawBroomLines - 몬테카를로 빗자루 차트에 그려지는 형 선의 수를 정의합니다. WarningLevel - 경고 수준을 변경할 수 있습니다. 레벨 1은 경고 수준이 4로 설정된 AFL 편집기 및 주석을 제외한 모든 AFL 실행에 대해 기본값입니다.
1 - 레벨 1 경고 만보고합니다 (502- 너무 많은 플롯).
2 - 보고 수준 1 및 2 경고 (위 조건에 더하기 할당, 0으로 나누기, 스레드 휴지 기간이 너무 깁니다)
3 - 보고 수준 1, 2 및 3 경고 (위와 마찬가지로 createobject / createstaticobject)
4- 모든 경고를보고합니다 (AFL 편집기의 기본값).
경고 : * 기호 별 * 옵션에서 옵션을 변경하면 백 테스트 실행시 모든 기호에 대해 OPTIONS가 일정하다고 가정하기 때문에 복합 결과 (예 : % 이익)는 DISTORTED가됩니다. 'HoldMinBars', 'EarlyExit'. & quot; 옵션은이 규칙에서 예외입니다 (즉, 심볼 단위로 안전하게 설정할 수 있음).
SetOption ( "AllowPositionShrinking", True);
아미 브로커 (Amibroker) 차트 옵션 설정
- 차트 창 옵션의 기본값을 설정 / 지우기 / 덮어 씁니다.
chartShowArrows, chartWrapTitle (4.75 이상), chartHideQuoteMarker (v5.06)입니다. chartHideQuoteMarker - 매개 변수 대화 상자 -> 축 및 격자 -> Vert와 같은 창 기준으로 견적 선택기 선을 숨 깁니다. quote marker : chartDisableYAxisCursor (5.80의 새로운 기능) - Y 축 위를 가리키면 마우스 포인터를 위 / 아래 화살표로 변경하는 것을 비활성화합니다. chartDisableTooltips (5.80에서 새로 추가) - 툴팁 표시 (데이터 팁)를 비활성화합니다.
gridFlags - (내부 AmiBroker 사용의 경우 - 이 매개 변수가 결국 제거되므로이 매개 변수는 사용자 코드에서 사용하지 마십시오) 허용되는 값은 chartGridDiv100, chartGridPercent, chartGridDiv1000, chartGridMargins chartGridMiddle, chartGrid0, chartGrid30, chartGrid70, chartGrid10, chartGrid90, chartGrid50, chartGrid100입니다. , chartGrid20, chartGrid80, chartGrid1 ymin, ymax - (5.07의 새로운 기능)이 매개 변수는 사용자 지정 배율에 대한 Y 축 최소값과 최대 값을 지정합니다. & quot; 화살표 표시 & quot;를 표시하기 위해 ymin // 조건을 충족하는 값을 지정하면 기본적으로 새 차트 용도로 사용됩니다.
SetChartOptions (0, chartShowArrows);
예 2 (버전 4.75 이상에서만 작동) :
SetChartOptions (2, chartWrapTitle);
제목 = & quot; 이것은 제목 텍스트의 자동 줄 바꿈 테스트로 한 줄에 들어 가지 않을 정도로 길기 때문에이 샘플 수식은 매우 긴 텍스트를 사용합니다. 샘플 & quot; ;
옵션 거래를 위해 Amibroker 차트를 게시 할 수 있습니까?
이전 스레드 / 게시물에서는 차트를 사용할 수 없습니다.
내 기술을 테스트하십시오. 차트를 게시하고 구매 / 판매 의사 결정 기술을 확인하십시오.
Android 용 차트 작성 앱을 게시하십시오.
어느 누구도이 차트의 AFL pls를 게시 할 수 있습니다.
누구든지 다음 차트에 afl을 게시 할 수 있습니까?
이 페이지를 공유하다.
인기있는 주식 중개인.
Rs 899 무제한 지분.
Rs 499 무제한 Curr.
또는 거래 당 Rs 15.
최저 거래 수수료.
최저 통화 및 & amp; 무역 수수료.
최저 스탬프 의무.
무료 주식 거래.
무역 당 20 루피.
직접 뮤추얼 펀드 투자.
60 일 동안 순이익을 낸 경우 100 % 중개 수수료 환급.
초보자, 숙련 된 투자자, 활성 상인 또는 HNI. 맞춤형 솔루션을 얻으십시오.
Rs 0 온라인 거래 + Demat Acct 계정 개설 수수료.
사용자 기술 자료.
2011 년 2 월 9 일
틱 수집 및 플로팅 v2.
아래 프로그램은 틱 기반 데이터를 수집하여 자체 창에 표시하는 방법을 보여줍니다.
참고 : 이전 버전에서는 오류가 수정되었지만 v2에서는 해당 날짜의 총 볼륨이 변경된 경우에만 틱을 수집합니다. 더 이상 문제가 있으면 언제든지보고하십시오 (기본 목록 또는 개인 제발).
이 예제는 Last, Bid 및 Ask price를 보여줍니다. 다른 유형의 틱 기반 데이터를 원하는만큼 자주 각 가격을 표시하는 네 줄을 반복 할 수 있습니다. 일반적인 차트는 다음과 같습니다.
틱 수집 및 플로팅에 관한 의견 끄기 v2.
2008 년 2 월 18 일.
TWS 수출 실행 보고서 읽기 / 백업.
이 코드를 테스트하기 전에 TWS 설정에 제공된 지시 사항에 따라 TWS를 설정하십시오. 여기에 제시된 코드는 실행 보고서를 읽어서. csv 형식으로 변환하고 날짜 스탬프를 찍어 나중에 사용하기 위해 백업하며 선택적으로 차트 제목에 표시합니다. 이 코드는 제목에 정보를 표시하는 것 외에도 중요한 작업을 수행하지 않습니다. 아이디어는 파일을 읽는 방법을 보여 주므로 실제 실행 가격을 추출하여 계산에 사용하고 차트에 플로팅 할 수 있습니다. Param 옵션은 자명하다.
TWS에 의해 생성 된 실행 보고서에 사용 된 이름에는 날짜가 표시되지 않습니다. 예를 들어, Simulated. Trades라는 이름으로 실행을 내보내기 위해 TWS를 설정하면이 동일한 이름이 다음 날에 사용됩니다. TWS가 전날의 트레이드리스트를 찾으면이를 덮어 씁니다. 이 AFL 읽기 가능 파일을 잃지 않게하려면 하루가 끝날 때 트레이드리스트를 백업해야합니다. TWS에서 내 보낸 실행 보고서의 형식은 다음과 같습니다.
아래 코드에 의해 생성 된 백업 파일의. csv 형식은 Excel로 직접 가져올 수 있으며 다음과 같습니다 (세미콜론은 쉼표로 바뀌 었음에 유의하십시오).
Excel에서 Text to columns를 활성화 한 후 파일은 다음과 같습니다.
TWS가 실행 보고서를 내보내는 최소 갱신 간격은 약 1 분입니다. 즉, 귀하의 거래가 목록에 나타나려면 약간의 시간이 걸릴 것입니다.
기본 백업 기능을 다루기 전에 필요한 몇 가지 도우미 기능이 있습니다. 이 사이트의 다른 곳에서도 사용할 수 있지만 편의를 위해 아래에 설명되어 있습니다. 서로 다른 프로그램에서 사용되는 정적 변수 간의 충돌을 막으려면 차트의 이름과 함께 이름을 입력해야합니다. 이에 대한 자세한 정보는 정적 변수 키 설정을 참조하십시오. DateNumToStr ()은 DateNumbers를 표준 날짜 문자열로 변환합니다.
아래 열거 된 TWSBackupTradeList (TWSInputPath)는 TWS 트레이드리스트를 읽고, 날짜를 추출하고,.csv 형식으로 변환하고, 다른 위치에 저장하며, 선택적으로 두 개의 트레이드리스트를 차트 제목에 표시합니다. 이 기능을 테스트하려면 새 인디케이터에 적용하고, 매개 변수 창을 열고, 매개 변수를 설정하고 백업을 클릭하십시오. 백업 파일은 TradebackupFolder 변수에 정의 된 경로에 저장됩니다. 함수가 실행 보고서를 찾고 Param 창에서 해당 표시가 켜져 있으면 제목에 다음과 같이 표시됩니다 (몇 줄만 표시).
그리고, 표시 될 때 백업 파일은 아래처럼 보입니다.
알 베노 사 편집.
TWS 수출 사형 집행 보고서 읽기 / 백업에 관한 의견.
실시간 바 기간 타이밍.
실시간으로 거래 할 때 새로운 기간이 시작되는시기와 기간이 끝나기 전에 남은 시간을 종종 알아야합니다. 아래 코드는 다음 막대의 남은 시간, 막대 시작 이후 경과 한 시간 및 날짜 변경 이후의 두 번째 횟수를 제공합니다. 타이밍 값은 선택한 차트 간격으로 자동 조정됩니다. 시스템의 코드에있는 변수를 사용하여 다양한 이벤트의 시간을 측정 할 수 있습니다.
이 코드는 데모 구성으로 표시되며 개인 요구 사항에 맞춰야합니다. 테스트하려면 표시기 창에 코드를 적용하기 만하면됩니다. 빠른 테스트를 위해 1 분 간격을 선택하십시오.
확인을 위해 타이밍이 차트 제목에 표시됩니다.
알 베노 사 편집.
Real-Time Bar Period Timing에 대한 의견이 없습니다.
2007 년 12 월 28 일.
실시간 바 기간 타이밍.
실시간 거래에서는 새 기간이 시작되는시기와 기간이 끝나기 전에 남은 시간을 종종 알아야합니다. 아래 코드는이 정보를 제공합니다. 시스템의 시계를 동기화하십시오.
테스트 및 코드 검증을 위해 타이밍이 차트 제목에 표시됩니다.
실시간 바 기간 타이밍에 대한 의견이 없습니다.
2007 년 11 월 10 일.
고정밀 지연 및 간격 타이밍.
이 게시물을 계속 읽기 전에 getPerformanceCounter ()에 대한 AmiBroker 도움말 항목을주의 깊게 읽어야합니다.
측정 시간은 모든 실시간 일중 거래 시스템의 중요한 측면입니다. 고해상도 타이밍이 필요한 일반적인 작업에는 다음이 포함됩니다. 대화 형 브로커 (IB) 로의 메시지 전송률을 50 / 초로 제한 (API 오류 100). 인터넷 지연을 허용하기 위해 IB 상태를 폴링하기 전에 작은 지연을 삽입합니다. 비틀 거리는 (interlacing) 포트폴리오 트레이드는 행동을 확산시킵니다. AFL 실행 시간 측정 및 최적화. 약간의 지연 후 주문 수정 (채우기 위해). 감시 목록 검색, 표시 및 상태 새로 고침, 느리게 변하는 변수를 기반으로 한 계산 등과 같은 작업의 주기적 실행. 시간 기록 이벤트 (예 : 주문 배치). 따옴표 수집 / 사전 처리. 보다 빠르고 쉬운 1 분 차트 관리에 라이브 틱 차트 오버레이.
이러한 작업의 대부분은 세 가지 사용자 지정 타이밍 함수를 사용하여 수행 할 수 있습니다. GetElapsedTime () : 재설정 후 경과 된 시간을 반환하는 함수입니다. SetDelay () : 미래 시간에 도달 할 시간을 반환하는 함수. GetDelayTrigger () : 지연 시간이 초과되면 트리거를 반환하는 함수입니다.
이 게시물은 데모 애플리케이션의 예제 기능을 제공합니다. 많은 타이머를 사용할 수 있도록 각 함수는 타이머 정보를 검색하는 데 사용할 TimerName을 제공해야합니다. 정적 변수는 전역 변수이며 어디서나 읽을 수 있습니다. 즉, 다른 창이나 창에서 동일한 TimerName을 사용하여 타이머를 상호 참조하지 않도록주의해야합니다. 동일한 코드의 여러 복사본을 실행하는 경우 TimerNames를 입력해야합니다. 이를 수행하는 방법에 대한 자세한 내용은 실시간 AFL 프로그래밍 범주의 정적 변수 입력을 참조하십시오.
아래의 타이머는 getPerformanceCounter ()를 사용하여 구현됩니다. 이 함수는 컴퓨터가 마지막으로 시작된 이후 경과 한 시간을 반환합니다. Tomasz는 최근 다음과 같이 설명했습니다. & # 8220; 기본 고주파 카운터는 컴퓨터 시작 이후 항상 실행됩니다. & # 8216; 재설정 & # 8217; 플래그는 실제로 마지막 값을 저장하므로 다음에 읽으면 마지막 값에서 빼서 차이를 둡니다. reset이 false이면 마지막 값은 0으로 설정되고 원래의 # 821 clock ticks를 얻습니다. 컴퓨터 시작 이후부터. & # 8220;
이 게시물의 타이머는 기본 고주파 카운터를 샘플링하며 getPerformanceCounter () Reset 인수는 항상 False로 설정되어 있습니다.
getPerformanceCounter ()는 마이크로 초 해상도의 값을 반환합니다. 그러나 실제적인 정확도는 컴퓨터 운영 체제의 중단으로 인해 심각하게 제한됩니다. 약 50 밀리 초의 절대 정확도보다 훨씬 좋을 것으로 기대하지 마십시오. 자신의 전용 트레이딩 하드웨어를 설계하는 것 (PC를 대체하기 위해) 이외에는 이것에 관해 할 수있는 것이 많지 않습니다. 용감한 사람이라면 작업 관리자 창에서 프로그램 우선 순위를 높이는 실험을 할 수 있습니다.
차트 새로 고침은 도착 인용에 의해 시작되는 경우가 가장 많지만 마우스 클릭, 툴팁 및 다양한 차트 작업으로 시작될 수도 있습니다. 즉, 시장 활동이 적고 원하는대로 빠르게 진행되지 않으면 차트를 클릭하여 AFL 실행을 강제로 수행 할 수 있습니다. 아래 코드를 실행하여이를 확인할 수 있으며 차트를 빠르게 클릭하는 동안 표시되는 타이머 수는 더 빠르게 업데이트됩니다.
RequestTimedRefresh (1)를 코드에 추가하여 1 초간의 차트 새로 고침을 보장 할 수 있습니다. 도착하는 데이터의 빈도가 느리면 AFL 코드가 산발적으로 만 실행될 수 있습니다. 타이머를 읽으려면 코드가 실행되어야하므로 타이머의 해상도는 차트 새로 고침 빈도에 의해 제한됩니다. 차트가 1 초에 한 번 새로 고침되면 시간 해상도가 1 초가됩니다!
일반적으로 표시기 윈도우의 대부분의 AFL 코드는 차트를 새로 고칠 때 실행됩니다. 그러나 속도면에서 이점을 얻으려면 타이머를 사용하여 코드의 중요하지 않은 섹션 (예 : 계정 정보 및 시스템 상태)을 자주 사용하지 않아도됩니다. 또한 잘 제어 된 루프 안에 코드를 배치하여 코드의 작은 섹션을 더 자주 실행할 수 있습니다. 이렇게하면 코드가 루프 내에서 소비 할 수있는 최대 시간을 1 초 이하로 제한하십시오.
빠른 거래 시스템의 경우 AFL 실행 빈도 (차트 새로 고침)가 느려질 수 있으며 이로 인해 LMT 채우기가 어려워 질 수 있습니다. 초당 20 회 실행하려면 패스 당 50 밀리 초를 필요로하는 프로그램을 가질 방법이 없습니다.
AFL 실행 사이의 간격을 고려하여 모든 이벤트가 가장 효율적인 순서로 처리되도록 코드의 레이아웃을 계획하는 것이 중요합니다. 원하지 않는 경우 주문의 투과율이 최대 1 초까지 지연 될 수 있습니다. 코드를 즉시 재실행 할 수있는 상황이 있습니다. 어떤 경우에는 다음 견적이나 새로 고침 전에 주문 상태를 확인하기 위해 주문을 한 후에이 작업을 원할 수 있습니다. RefreshAll ()을 호출하면이 메소드를 거의 사용하지 않아도됩니다.
알 베노 사 편집.
고정밀 지연 및 간격 타이밍에 대한 의견이 없습니다.
2007 년 10 월 16 일.
실시간 데이터를위한 백필 탐색.
백필 데이터는 여러 가지 방법으로 수행 할 수 있으며 다른 데이터 공급자마다 서로 다른 방법이 필요할 수 있습니다. 아래에 표시된 방법은 eSignal 데이터 용으로 개발되었습니다. 다른 데이터 공급자를 사용하는 경우 코드 및 절차를 수정해야 할 수 있습니다.
데이터를 백필 할 때, 데이터가 올바르게 채워지는지 확인하고 데이터 홀의 존재 여부에 대한 표시가 있어야합니다. Real-Time Trading의 Data Holes에서 지적했듯이, 구멍을 탐지하기 위해서는 데이터를 비교할 수있는 완벽한 데이터 배열이 필요합니다. AmiBroker에는 이러한 데이터 배열이 없으므로 여기에 제시된 방법은 참조 시세로 QQQQ를 사용합니다. 켜기 및 등 처자 설정 - & gt; 일반 - & gt; 모든 데이터를 기준 기호에 맞추고 정렬 - & gt; QQQQ. 모든 시세 표시를 다시 채우려면 백필 기다리기 (RT 전용)를 켜야합니다. 실시간 백필 속도를 높이려면 복잡한 코드 대신 간단한 가격 차트 만 표시하는 것이 좋습니다. 복잡한 지표 또는 시스템을 새로 고치면 백필 속도가 느려집니다. 다음 탐험은 감시 목록에 모든 시세 표시기를 채워 넣고 성공 여부를보고합니다.
2007 년 10 월 11 일
차트를 오른쪽 맞춤으로 유지.
실시간 거래에서 차트의 오른쪽 정렬을 유지하는 것, 즉 가장 오른쪽의 가격 표시 막대가 항상 표시되도록하는 것이 중요합니다. 그렇게하지 않으면 진짜 돈을 거래 할 때 잘못된 막대를 보면서 상인이 공황 반응을 일으켜 잘못된 위치를 잘못 잡거나 잘못된 순서로 놓는 결과를 낳을 수 있습니다. 이는 여러 컴퓨터를 실행하고 있고 항상 거래중인 차트를 모니터링하지 않는 경우에 쉽게 발생할 수 있습니다.
다음 코드는 시스템 시작시 또는 Param 창에서 차트를 오른쪽 정렬 할 수있는 방법을 보여줍니다. 마지막 막대가 보이지 않을 때 차트의 바탕색을 변경하는 시각적 경고가 포함됩니다.
알람은 DateTime ()을 사용하여 차트의 오른쪽 가장자리에있는 빈 막대를 자동으로 수정합니다. 코드는 명시 적으로 유지되므로 속도를 위해 최적화 할 수 있습니다.
알 베노 사 편집.
차트를 오른쪽 맞춤으로 유지하는 것에 대한 의견 없음.
2007 년 9 월 23 일.
AFL 실행 시간 측정 (v3)
코드의 복잡성이 증가하면 코드 실행 속도가 느려지므로 결국 코드를 최적화하여 실행 속도를 높일 수 있습니다. 더 빠른 컴퓨터를 구매하려고해도 코드를 최적화하는 것보다 속도면에서 훨씬 유리합니다.
중요 사항 : 2007 년 5 월 10 일에 릴리스 된 AmiBroker 5.01.1 베타는 새로운 AmiBroker 및 사용자 정의 함수에 대한 정확한 성능 타이밍을 얻을 수있는 새로운 프로파일 링 기능을 제공합니다. AFL 편집기에서 도구 -> 코드 검사 및 프로파일 메뉴를 사용할 수 있습니다. 이 새로운 도구를 효과적으로 사용하려면 가능한 많이 코드 모듈을 함수 호출로 변환해야합니다. 시도 해봐!
AFL 실행 속도를 분석하는 첫 번째 요구 사항은 실행 시간을 측정하는 것입니다. 이는 마이크로 초 해상도를 제공하는 GetPerformanceCounter ()를 사용하는 것이 가장 좋습니다. 차트 제목에 실행 시간을 표시하거나 DebugView에 기록 할 수 있습니다. AFL 실행 속도에 대한 감사를 받으려면 가장 자주 사용되는 AFL 문 몇 가지를 실행해야 할 수 있습니다. Tomasz가이 게시물의 이전 버전에 대한 자신의 의견에서 지적했듯이 간단한 루프를 사용하여이를 수행 할 수 있습니다.
DebugView에서 생성 된 출력은 다음과 같습니다.
제목의 출력은 다음과 같습니다.
Title의 첫 번째 읽기는 PerformanceCounter를 초기화 할 때 무시해야합니다. 이 판독 값은 DebugView 로그의 DBViewClear 명령에 의해 표시되지 않습니다. 위의 방법은 모든 AFL 기능의 실행 시간을 결정하는 데 사용할 수 있습니다. 위 예제에서 SetBarsRequired ()는 사용 가능한 모든 데이터를 처리하는 데 사용됩니다. 이것은 최악의 경우의 측정 일 것입니다. SetBarsRequired ()를 주석 처리하면 Quick-AFL에서 코드가 실행됩니다. 이는 모든 데이터를 실행하는 것보다 훨씬 빠릅니다.
창 창에 대한 실행 순서 및 타이밍 측정.
여러 창 또는 창에서 AFL 수식을 실행하고 타이밍 문제가 발생할 때 위의 방법을 사용하기 전에 수행해야 할 첫 번째 단계는 어느 창에서 너무 많은 시간을 사용하는지 결정하는 것입니다. Tools -> Preferences -> Miscelaneous -> Display Chart Timing을 켜서 차트 하단의 실행 시간을 읽을 수 있습니다. 또는 아래의 간단한 코드를 사용하여 열려있는 각 창에서 수식의 실행 순서와 시간을 DebugView에 기록 할 수 있습니다. AmiBroker 성능 카운터 판독 값은 각 창마다 고유하므로 아래 코드는이를 사용하지 않습니다. 이 경우 Options -> DebugView의 Milliseconds 표시를 켜야합니다. 이렇게하면 성능 카운터와 마찬가지로 초 단위가 아니라 밀리 초 단위의 분해능을 얻을 수 있으며 매우 근접한 측정 값입니다. 문제 공식을 식별하는 데에만 사용해야합니다. pane의 실행 순서는 DebugView에 선이 나타나는 순서에 따라 표시됩니다.
파일 이름 할당 및 TraceChartID () 코드의 맨 위에 배치해야합니다 또는 기본 포함 파일에 추가 할 수 있습니다. 이 함수를 호출하는 데 사용되는 단일 행은 각 창 / 창에있는 코드의 시작과 끝 모두에 있어야합니다. 이것은 DebugView에서 다음과 같습니다.
알 베노 사 편집.
2007 년 7 월 21 일.
실시간 지연.
실시간 거래에서 특정 기준이 충족 될 때까지 작업을 지연하려는 경우 많은 상황이 발생합니다. AmiBroker에서는 여러 가지 방법으로 지연을 지정할 수 있습니다. 단 하나의 요구 사항은 지연 변수가 증가 또는 감소한다는 것입니다. 선택한 변수가 시간 초과 값 (목표)으로 되돌아 가지 않으면 지연 기능이 절대로 시간 초과되지 않습니다. 이 경우 해당 조건을 처리하는 코드를 추가해야합니다. 몇 가지 변수를 사용할 수 있습니다 :
& # 8211; 경과 된 초 (재 작업).
& # 8211; 실시간 데이터 타임 스탬프 (TimeNum ()).
& # 8211; 볼륨 (볼륨 변경).
& # 8211; 가격 변동 (가격 변동).
& # 8211; 차트 새로 고침 (모든 AFL 실행).
위의 변수 중 지연에 사용할 변수는 거래 시스템의 요구 사항에 따라 다릅니다. 필요한 결과를 얻으려면 여러 가지 방법을 결합해야 할 수도 있습니다. 예를 들어 지연이 데이터 타임 스탬프를 기반으로 한 경우 데이터가 손실되거나 거래가 없을 때 시간이 초과되지 않을 수 있습니다. 이 경우 실시간 (초) 지연으로 데이터 타임 스탬프 지연을 백업해야합니다.
지연은 실시간 시스템 설계에서 중요한 역할을합니다. 예를 들어, 실시간 시스템에서 신호의 수명이 짧을 수 있습니다. 신호는 트리거 할 때 가장 강하고 몇 마디 후에는 모든 의미를 잃을 때까지 빠르게 사라집니다. 그것이 중요성을 잃었을 때 주문을 채우게하는 것은 순수한 도박입니다. 이를 방지하기 위해 지연 후 주문을 취소하거나 신호 강도의 감지 된 감쇠에 비례하여 위치 크기를 줄일 수 있습니다 (경과 막대에 따라 다름).
실시간 시스템에서 AFL 실행 간의 시간 경과가 중요 할 수 있으므로 LMT 가격 계산을 주문 코드보다 우선해야합니다. Calculating the LMT price after the order has been placed postpones order placement until the next AFL execution occurs, i. e., when the next quote arrives; by then, the price has probably changed. Especially during periods of low volume, this could be significant. When these delays would be insignificant in EOD systems, they could make-or-break your system in fast-trading systems.
To ensure frequent AFL execution in the absence of quotes, you can place a RequestTimedRefresh(1) statement at the top of your code, where the variable ‘1’ refers to a 1-second refresh. This guarantees an AFL execution at least once per second.
If your code is lengthy and takes a significant amount of time to execute, you may have to check order status at several places in your code. If changed status demands immediate action, you can force an immediate AFL execution by calling the following function:
July 14, 2007.
Preventing Repeat Orders and Whipsaws.
When you are developing a Real-Time trading system, often the first problem you have to solve is to prevent repeat orders. Repeat orders can occur when a signal remains true over several bars or chart refreshes, and each new bar/refresh sends out a new order. This can result in unintentional pyramiding.
Another ordering problem can occur when your entry and exit prices are too close together with respect to price volatility. In this case, the price volatility can whipsaw you in and out of positions in rapid succession. When this happens, slippage and commissions will quickly erode any profits you may have had. Also, if your system cannot keep up with each signal, you may end up in an opposing trade.
A common mistake when attempting to prevent repeat orders is to wait for order confirmation from the TWS after each partial fill. The problem here is that confirmations from the TWS are always subject to significant delay, and they will often let several repeat orders slip through before the acknowledgment is received.
Another flawed method is to filter or smooth the price arrays. Although this may prevent repeat orders, the lag introduced by this technique will kill most systems.
There is no single best way to prevent repeat orders. Your solution will depend on your personal preferences and the principle of your trading system. Under certain conditions you may want to combine several of the methods shown below. The examples presented here are intended to make you aware of the problems involved and suggest some possible solutions. It is your responsibility to modify the code to suit your particular system’s requirements.
To test the demo codes below, you will need to have the TWS running and connected to the IB eDemo or your paper trading account. To keep the programs below as simple as possible, you have to reset the programs after changing the Transmit ParamToggle from Off to On.
Using OrderIDs to prevent repeat orders.
When your program calls the PlaceOrder() or ModifyOrder() function, the IBc returns a unique OrderID. The OrderID uniquely identifies the order you placed so that you can refer to it later to modify, cancel, or check order status. The OrderID only acknowledges that the order was placed; it does not mean that the order was transmitted to the market or was filled.
If an OrderID has been received, this means that the order was placed. You can prevent order repeats by checking whether the OrderID has a value. Then, if you only place orders when the OrderID is empty, you cannot place repeat orders. The first example below lets you explore this procedure.
After an order has been filled or cancelled, you may eventually want to transmit a new order. In this case, you will have to define a rule for clearing the OrderID. This rule can be based on order status, a contrary signal, a time delay, the start of a new bar, or any number of things. Note that after you have cleared an OrderID, you can no longer modify or cancel the order it referred to. Hence, you should only clear an OrderID if you are sure that the OrderID is no longer needed, i. e., the order was confirmed cancelled, filled, or rejected.
The method below demonstrates how to use the OrderID, and because it still allows you to enter and exit (whipsaw) a position within milliseconds, it is only a first step to preventing repeats and whipsaws. To run this demo, Insert the code into a chart pane. When you open the Param window you will see these options:
The Chart Title shows IBc connection, OrderID, and Position status. Note that while Interactive Brokers calls all the messages ‘error’ messages, many are just harmless notifications. For more details on these error messages see API Error Messages.
When you click the Buy button, the Title will display the OrderID for the order placed, Order Status, and the position size if the order was filled. If you watch closely when you place an order, you may see order status change, for example from PreSubmitted to Filled :
In this demo you clear the OrderIDs manually. In a real system it would be cleared when your system is ready to allow the next order to go out.
Clearing OrderIDs at the Start of a New Bar.
In this example the OrderIDs are automatically cleared at the start of a new bar. This limits each type of trade (Buy, Sell, short, or Cover) to one per bar. If you want to place a new order while an order is pending, you may either cancel it first or modify the pending order.
Since the start of a new bar can only be detected when its first quote arrives, it is impossible to get a fill at this time. The earliest time an order can be filled is on the second quote of the bar. How long this takes depends on market volume and whether you use eSignal (trades) or IB data (snapshots). Since the Opening quote can occur at any time during the bar interval, it may take from zero to the full bar interval before the OrderIDs are cleared. To prevent this delay, you can clear the orders with reference to your system’s clock. However, this requires that your system is perfectly synchronized with the market-time (see next example).
The best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
The chart background will flash Green when a Buy order is placed, Red when a Sell order is placed, and White when a NewBar is started. You can test blocking of repeat orders by manually placing orders in rapid succession. The example code below will only place one Buy and/or Sell order during each bar-period (between White flashes). This method does allow you to take quick profits when both your entry and exit price are hit within one bar period. However you can do this only once per bar.
Clearing OrderIDs after a Delay.
This example maintains a delay between same-type orders. It uses a delay-timer for each type of trade and clears the OrderIDs when the delay times out.
If you set the delay to the bar-interval and if your system clock were synchronized with the market , then this method would give similar results to the NewBar method discussed earlier. However, this method is better since it enables you to place your LMT orders before the Open of the bar, thus giving you a one-quote timing advantage. This may not sound like much, but in fast trading, especially during moderate trading volume, this improves your chances of getting LMT fills.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Experiment with the parameter options and observe that you cannot place a same-type order before the delay has timed out (see Chart Title).
If your system trades LMT orders, you can design your orders to alternate between Long and Short without any limitations.
This method is well suited for reversal systems and high speed trading.
If your limit prices are set properly, this method will allow a fast sequence of reversal trades that can be very profitable. Systems like this may make several trades per minute, sometimes for several minutes, during high volatility.
In the following example, Order Status is checked, and an opposite order is only allowed to pass if the previous order has been filled. Note that this demo does not work if the Transmit ParamToggle is turned Off because under that condition no orders are transmitted to the market and can thus never be filled.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
알 베노 사 편집.
Comments Off on Preventing Repeat Orders and Whipsaws.
최근 게시물.
최근 댓글.
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.357 seconds.
- 차트 창 옵션의 기본값을 설정 / 지우기 / 덮어 씁니다.
chartShowArrows, chartWrapTitle (4.75 이상), chartHideQuoteMarker (v5.06)입니다. chartHideQuoteMarker - 매개 변수 대화 상자 -> 축 및 격자 -> Vert와 같은 창 기준으로 견적 선택기 선을 숨 깁니다. quote marker : chartDisableYAxisCursor (5.80의 새로운 기능) - Y 축 위를 가리키면 마우스 포인터를 위 / 아래 화살표로 변경하는 것을 비활성화합니다. chartDisableTooltips (5.80에서 새로 추가) - 툴팁 표시 (데이터 팁)를 비활성화합니다.
gridFlags - (내부 AmiBroker 사용의 경우 - 이 매개 변수가 결국 제거되므로이 매개 변수는 사용자 코드에서 사용하지 마십시오) 허용되는 값은 chartGridDiv100, chartGridPercent, chartGridDiv1000, chartGridMargins chartGridMiddle, chartGrid0, chartGrid30, chartGrid70, chartGrid10, chartGrid90, chartGrid50, chartGrid100입니다. , chartGrid20, chartGrid80, chartGrid1 ymin, ymax - (5.07의 새로운 기능)이 매개 변수는 사용자 지정 배율에 대한 Y 축 최소값과 최대 값을 지정합니다. & quot; 화살표 표시 & quot;를 표시하기 위해 ymin // 조건을 충족하는 값을 지정하면 기본적으로 새 차트 용도로 사용됩니다.
SetChartOptions (0, chartShowArrows);
예 2 (버전 4.75 이상에서만 작동) :
SetChartOptions (2, chartWrapTitle);
제목 = & quot; 이것은 제목 텍스트의 자동 줄 바꿈 테스트로 한 줄에 들어 가지 않을 정도로 길기 때문에이 샘플 수식은 매우 긴 텍스트를 사용합니다. 샘플 & quot; ;
옵션 거래를 위해 Amibroker 차트를 게시 할 수 있습니까?
이전 스레드 / 게시물에서는 차트를 사용할 수 없습니다.
내 기술을 테스트하십시오. 차트를 게시하고 구매 / 판매 의사 결정 기술을 확인하십시오.
Android 용 차트 작성 앱을 게시하십시오.
어느 누구도이 차트의 AFL pls를 게시 할 수 있습니다.
누구든지 다음 차트에 afl을 게시 할 수 있습니까?
이 페이지를 공유하다.
인기있는 주식 중개인.
Rs 899 무제한 지분.
Rs 499 무제한 Curr.
또는 거래 당 Rs 15.
최저 거래 수수료.
최저 통화 및 & amp; 무역 수수료.
최저 스탬프 의무.
무료 주식 거래.
무역 당 20 루피.
직접 뮤추얼 펀드 투자.
60 일 동안 순이익을 낸 경우 100 % 중개 수수료 환급.
초보자, 숙련 된 투자자, 활성 상인 또는 HNI. 맞춤형 솔루션을 얻으십시오.
Rs 0 온라인 거래 + Demat Acct 계정 개설 수수료.
사용자 기술 자료.
2011 년 2 월 9 일
틱 수집 및 플로팅 v2.
아래 프로그램은 틱 기반 데이터를 수집하여 자체 창에 표시하는 방법을 보여줍니다.
참고 : 이전 버전에서는 오류가 수정되었지만 v2에서는 해당 날짜의 총 볼륨이 변경된 경우에만 틱을 수집합니다. 더 이상 문제가 있으면 언제든지보고하십시오 (기본 목록 또는 개인 제발).
이 예제는 Last, Bid 및 Ask price를 보여줍니다. 다른 유형의 틱 기반 데이터를 원하는만큼 자주 각 가격을 표시하는 네 줄을 반복 할 수 있습니다. 일반적인 차트는 다음과 같습니다.
틱 수집 및 플로팅에 관한 의견 끄기 v2.
2008 년 2 월 18 일.
TWS 수출 실행 보고서 읽기 / 백업.
이 코드를 테스트하기 전에 TWS 설정에 제공된 지시 사항에 따라 TWS를 설정하십시오. 여기에 제시된 코드는 실행 보고서를 읽어서. csv 형식으로 변환하고 날짜 스탬프를 찍어 나중에 사용하기 위해 백업하며 선택적으로 차트 제목에 표시합니다. 이 코드는 제목에 정보를 표시하는 것 외에도 중요한 작업을 수행하지 않습니다. 아이디어는 파일을 읽는 방법을 보여 주므로 실제 실행 가격을 추출하여 계산에 사용하고 차트에 플로팅 할 수 있습니다. Param 옵션은 자명하다.
TWS에 의해 생성 된 실행 보고서에 사용 된 이름에는 날짜가 표시되지 않습니다. 예를 들어, Simulated. Trades라는 이름으로 실행을 내보내기 위해 TWS를 설정하면이 동일한 이름이 다음 날에 사용됩니다. TWS가 전날의 트레이드리스트를 찾으면이를 덮어 씁니다. 이 AFL 읽기 가능 파일을 잃지 않게하려면 하루가 끝날 때 트레이드리스트를 백업해야합니다. TWS에서 내 보낸 실행 보고서의 형식은 다음과 같습니다.
아래 코드에 의해 생성 된 백업 파일의. csv 형식은 Excel로 직접 가져올 수 있으며 다음과 같습니다 (세미콜론은 쉼표로 바뀌 었음에 유의하십시오).
Excel에서 Text to columns를 활성화 한 후 파일은 다음과 같습니다.
TWS가 실행 보고서를 내보내는 최소 갱신 간격은 약 1 분입니다. 즉, 귀하의 거래가 목록에 나타나려면 약간의 시간이 걸릴 것입니다.
기본 백업 기능을 다루기 전에 필요한 몇 가지 도우미 기능이 있습니다. 이 사이트의 다른 곳에서도 사용할 수 있지만 편의를 위해 아래에 설명되어 있습니다. 서로 다른 프로그램에서 사용되는 정적 변수 간의 충돌을 막으려면 차트의 이름과 함께 이름을 입력해야합니다. 이에 대한 자세한 정보는 정적 변수 키 설정을 참조하십시오. DateNumToStr ()은 DateNumbers를 표준 날짜 문자열로 변환합니다.
아래 열거 된 TWSBackupTradeList (TWSInputPath)는 TWS 트레이드리스트를 읽고, 날짜를 추출하고,.csv 형식으로 변환하고, 다른 위치에 저장하며, 선택적으로 두 개의 트레이드리스트를 차트 제목에 표시합니다. 이 기능을 테스트하려면 새 인디케이터에 적용하고, 매개 변수 창을 열고, 매개 변수를 설정하고 백업을 클릭하십시오. 백업 파일은 TradebackupFolder 변수에 정의 된 경로에 저장됩니다. 함수가 실행 보고서를 찾고 Param 창에서 해당 표시가 켜져 있으면 제목에 다음과 같이 표시됩니다 (몇 줄만 표시).
그리고, 표시 될 때 백업 파일은 아래처럼 보입니다.
알 베노 사 편집.
TWS 수출 사형 집행 보고서 읽기 / 백업에 관한 의견.
실시간 바 기간 타이밍.
실시간으로 거래 할 때 새로운 기간이 시작되는시기와 기간이 끝나기 전에 남은 시간을 종종 알아야합니다. 아래 코드는 다음 막대의 남은 시간, 막대 시작 이후 경과 한 시간 및 날짜 변경 이후의 두 번째 횟수를 제공합니다. 타이밍 값은 선택한 차트 간격으로 자동 조정됩니다. 시스템의 코드에있는 변수를 사용하여 다양한 이벤트의 시간을 측정 할 수 있습니다.
이 코드는 데모 구성으로 표시되며 개인 요구 사항에 맞춰야합니다. 테스트하려면 표시기 창에 코드를 적용하기 만하면됩니다. 빠른 테스트를 위해 1 분 간격을 선택하십시오.
확인을 위해 타이밍이 차트 제목에 표시됩니다.
알 베노 사 편집.
Real-Time Bar Period Timing에 대한 의견이 없습니다.
2007 년 12 월 28 일.
실시간 바 기간 타이밍.
실시간 거래에서는 새 기간이 시작되는시기와 기간이 끝나기 전에 남은 시간을 종종 알아야합니다. 아래 코드는이 정보를 제공합니다. 시스템의 시계를 동기화하십시오.
테스트 및 코드 검증을 위해 타이밍이 차트 제목에 표시됩니다.
실시간 바 기간 타이밍에 대한 의견이 없습니다.
2007 년 11 월 10 일.
고정밀 지연 및 간격 타이밍.
이 게시물을 계속 읽기 전에 getPerformanceCounter ()에 대한 AmiBroker 도움말 항목을주의 깊게 읽어야합니다.
측정 시간은 모든 실시간 일중 거래 시스템의 중요한 측면입니다. 고해상도 타이밍이 필요한 일반적인 작업에는 다음이 포함됩니다. 대화 형 브로커 (IB) 로의 메시지 전송률을 50 / 초로 제한 (API 오류 100). 인터넷 지연을 허용하기 위해 IB 상태를 폴링하기 전에 작은 지연을 삽입합니다. 비틀 거리는 (interlacing) 포트폴리오 트레이드는 행동을 확산시킵니다. AFL 실행 시간 측정 및 최적화. 약간의 지연 후 주문 수정 (채우기 위해). 감시 목록 검색, 표시 및 상태 새로 고침, 느리게 변하는 변수를 기반으로 한 계산 등과 같은 작업의 주기적 실행. 시간 기록 이벤트 (예 : 주문 배치). 따옴표 수집 / 사전 처리. 보다 빠르고 쉬운 1 분 차트 관리에 라이브 틱 차트 오버레이.
이러한 작업의 대부분은 세 가지 사용자 지정 타이밍 함수를 사용하여 수행 할 수 있습니다. GetElapsedTime () : 재설정 후 경과 된 시간을 반환하는 함수입니다. SetDelay () : 미래 시간에 도달 할 시간을 반환하는 함수. GetDelayTrigger () : 지연 시간이 초과되면 트리거를 반환하는 함수입니다.
이 게시물은 데모 애플리케이션의 예제 기능을 제공합니다. 많은 타이머를 사용할 수 있도록 각 함수는 타이머 정보를 검색하는 데 사용할 TimerName을 제공해야합니다. 정적 변수는 전역 변수이며 어디서나 읽을 수 있습니다. 즉, 다른 창이나 창에서 동일한 TimerName을 사용하여 타이머를 상호 참조하지 않도록주의해야합니다. 동일한 코드의 여러 복사본을 실행하는 경우 TimerNames를 입력해야합니다. 이를 수행하는 방법에 대한 자세한 내용은 실시간 AFL 프로그래밍 범주의 정적 변수 입력을 참조하십시오.
아래의 타이머는 getPerformanceCounter ()를 사용하여 구현됩니다. 이 함수는 컴퓨터가 마지막으로 시작된 이후 경과 한 시간을 반환합니다. Tomasz는 최근 다음과 같이 설명했습니다. & # 8220; 기본 고주파 카운터는 컴퓨터 시작 이후 항상 실행됩니다. & # 8216; 재설정 & # 8217; 플래그는 실제로 마지막 값을 저장하므로 다음에 읽으면 마지막 값에서 빼서 차이를 둡니다. reset이 false이면 마지막 값은 0으로 설정되고 원래의 # 821 clock ticks를 얻습니다. 컴퓨터 시작 이후부터. & # 8220;
이 게시물의 타이머는 기본 고주파 카운터를 샘플링하며 getPerformanceCounter () Reset 인수는 항상 False로 설정되어 있습니다.
getPerformanceCounter ()는 마이크로 초 해상도의 값을 반환합니다. 그러나 실제적인 정확도는 컴퓨터 운영 체제의 중단으로 인해 심각하게 제한됩니다. 약 50 밀리 초의 절대 정확도보다 훨씬 좋을 것으로 기대하지 마십시오. 자신의 전용 트레이딩 하드웨어를 설계하는 것 (PC를 대체하기 위해) 이외에는 이것에 관해 할 수있는 것이 많지 않습니다. 용감한 사람이라면 작업 관리자 창에서 프로그램 우선 순위를 높이는 실험을 할 수 있습니다.
차트 새로 고침은 도착 인용에 의해 시작되는 경우가 가장 많지만 마우스 클릭, 툴팁 및 다양한 차트 작업으로 시작될 수도 있습니다. 즉, 시장 활동이 적고 원하는대로 빠르게 진행되지 않으면 차트를 클릭하여 AFL 실행을 강제로 수행 할 수 있습니다. 아래 코드를 실행하여이를 확인할 수 있으며 차트를 빠르게 클릭하는 동안 표시되는 타이머 수는 더 빠르게 업데이트됩니다.
RequestTimedRefresh (1)를 코드에 추가하여 1 초간의 차트 새로 고침을 보장 할 수 있습니다. 도착하는 데이터의 빈도가 느리면 AFL 코드가 산발적으로 만 실행될 수 있습니다. 타이머를 읽으려면 코드가 실행되어야하므로 타이머의 해상도는 차트 새로 고침 빈도에 의해 제한됩니다. 차트가 1 초에 한 번 새로 고침되면 시간 해상도가 1 초가됩니다!
일반적으로 표시기 윈도우의 대부분의 AFL 코드는 차트를 새로 고칠 때 실행됩니다. 그러나 속도면에서 이점을 얻으려면 타이머를 사용하여 코드의 중요하지 않은 섹션 (예 : 계정 정보 및 시스템 상태)을 자주 사용하지 않아도됩니다. 또한 잘 제어 된 루프 안에 코드를 배치하여 코드의 작은 섹션을 더 자주 실행할 수 있습니다. 이렇게하면 코드가 루프 내에서 소비 할 수있는 최대 시간을 1 초 이하로 제한하십시오.
빠른 거래 시스템의 경우 AFL 실행 빈도 (차트 새로 고침)가 느려질 수 있으며 이로 인해 LMT 채우기가 어려워 질 수 있습니다. 초당 20 회 실행하려면 패스 당 50 밀리 초를 필요로하는 프로그램을 가질 방법이 없습니다.
AFL 실행 사이의 간격을 고려하여 모든 이벤트가 가장 효율적인 순서로 처리되도록 코드의 레이아웃을 계획하는 것이 중요합니다. 원하지 않는 경우 주문의 투과율이 최대 1 초까지 지연 될 수 있습니다. 코드를 즉시 재실행 할 수있는 상황이 있습니다. 어떤 경우에는 다음 견적이나 새로 고침 전에 주문 상태를 확인하기 위해 주문을 한 후에이 작업을 원할 수 있습니다. RefreshAll ()을 호출하면이 메소드를 거의 사용하지 않아도됩니다.
알 베노 사 편집.
고정밀 지연 및 간격 타이밍에 대한 의견이 없습니다.
2007 년 10 월 16 일.
실시간 데이터를위한 백필 탐색.
백필 데이터는 여러 가지 방법으로 수행 할 수 있으며 다른 데이터 공급자마다 서로 다른 방법이 필요할 수 있습니다. 아래에 표시된 방법은 eSignal 데이터 용으로 개발되었습니다. 다른 데이터 공급자를 사용하는 경우 코드 및 절차를 수정해야 할 수 있습니다.
데이터를 백필 할 때, 데이터가 올바르게 채워지는지 확인하고 데이터 홀의 존재 여부에 대한 표시가 있어야합니다. Real-Time Trading의 Data Holes에서 지적했듯이, 구멍을 탐지하기 위해서는 데이터를 비교할 수있는 완벽한 데이터 배열이 필요합니다. AmiBroker에는 이러한 데이터 배열이 없으므로 여기에 제시된 방법은 참조 시세로 QQQQ를 사용합니다. 켜기 및 등 처자 설정 - & gt; 일반 - & gt; 모든 데이터를 기준 기호에 맞추고 정렬 - & gt; QQQQ. 모든 시세 표시를 다시 채우려면 백필 기다리기 (RT 전용)를 켜야합니다. 실시간 백필 속도를 높이려면 복잡한 코드 대신 간단한 가격 차트 만 표시하는 것이 좋습니다. 복잡한 지표 또는 시스템을 새로 고치면 백필 속도가 느려집니다. 다음 탐험은 감시 목록에 모든 시세 표시기를 채워 넣고 성공 여부를보고합니다.
2007 년 10 월 11 일
차트를 오른쪽 맞춤으로 유지.
실시간 거래에서 차트의 오른쪽 정렬을 유지하는 것, 즉 가장 오른쪽의 가격 표시 막대가 항상 표시되도록하는 것이 중요합니다. 그렇게하지 않으면 진짜 돈을 거래 할 때 잘못된 막대를 보면서 상인이 공황 반응을 일으켜 잘못된 위치를 잘못 잡거나 잘못된 순서로 놓는 결과를 낳을 수 있습니다. 이는 여러 컴퓨터를 실행하고 있고 항상 거래중인 차트를 모니터링하지 않는 경우에 쉽게 발생할 수 있습니다.
다음 코드는 시스템 시작시 또는 Param 창에서 차트를 오른쪽 정렬 할 수있는 방법을 보여줍니다. 마지막 막대가 보이지 않을 때 차트의 바탕색을 변경하는 시각적 경고가 포함됩니다.
알람은 DateTime ()을 사용하여 차트의 오른쪽 가장자리에있는 빈 막대를 자동으로 수정합니다. 코드는 명시 적으로 유지되므로 속도를 위해 최적화 할 수 있습니다.
알 베노 사 편집.
차트를 오른쪽 맞춤으로 유지하는 것에 대한 의견 없음.
2007 년 9 월 23 일.
AFL 실행 시간 측정 (v3)
코드의 복잡성이 증가하면 코드 실행 속도가 느려지므로 결국 코드를 최적화하여 실행 속도를 높일 수 있습니다. 더 빠른 컴퓨터를 구매하려고해도 코드를 최적화하는 것보다 속도면에서 훨씬 유리합니다.
중요 사항 : 2007 년 5 월 10 일에 릴리스 된 AmiBroker 5.01.1 베타는 새로운 AmiBroker 및 사용자 정의 함수에 대한 정확한 성능 타이밍을 얻을 수있는 새로운 프로파일 링 기능을 제공합니다. AFL 편집기에서 도구 -> 코드 검사 및 프로파일 메뉴를 사용할 수 있습니다. 이 새로운 도구를 효과적으로 사용하려면 가능한 많이 코드 모듈을 함수 호출로 변환해야합니다. 시도 해봐!
AFL 실행 속도를 분석하는 첫 번째 요구 사항은 실행 시간을 측정하는 것입니다. 이는 마이크로 초 해상도를 제공하는 GetPerformanceCounter ()를 사용하는 것이 가장 좋습니다. 차트 제목에 실행 시간을 표시하거나 DebugView에 기록 할 수 있습니다. AFL 실행 속도에 대한 감사를 받으려면 가장 자주 사용되는 AFL 문 몇 가지를 실행해야 할 수 있습니다. Tomasz가이 게시물의 이전 버전에 대한 자신의 의견에서 지적했듯이 간단한 루프를 사용하여이를 수행 할 수 있습니다.
DebugView에서 생성 된 출력은 다음과 같습니다.
제목의 출력은 다음과 같습니다.
Title의 첫 번째 읽기는 PerformanceCounter를 초기화 할 때 무시해야합니다. 이 판독 값은 DebugView 로그의 DBViewClear 명령에 의해 표시되지 않습니다. 위의 방법은 모든 AFL 기능의 실행 시간을 결정하는 데 사용할 수 있습니다. 위 예제에서 SetBarsRequired ()는 사용 가능한 모든 데이터를 처리하는 데 사용됩니다. 이것은 최악의 경우의 측정 일 것입니다. SetBarsRequired ()를 주석 처리하면 Quick-AFL에서 코드가 실행됩니다. 이는 모든 데이터를 실행하는 것보다 훨씬 빠릅니다.
창 창에 대한 실행 순서 및 타이밍 측정.
여러 창 또는 창에서 AFL 수식을 실행하고 타이밍 문제가 발생할 때 위의 방법을 사용하기 전에 수행해야 할 첫 번째 단계는 어느 창에서 너무 많은 시간을 사용하는지 결정하는 것입니다. Tools -> Preferences -> Miscelaneous -> Display Chart Timing을 켜서 차트 하단의 실행 시간을 읽을 수 있습니다. 또는 아래의 간단한 코드를 사용하여 열려있는 각 창에서 수식의 실행 순서와 시간을 DebugView에 기록 할 수 있습니다. AmiBroker 성능 카운터 판독 값은 각 창마다 고유하므로 아래 코드는이를 사용하지 않습니다. 이 경우 Options -> DebugView의 Milliseconds 표시를 켜야합니다. 이렇게하면 성능 카운터와 마찬가지로 초 단위가 아니라 밀리 초 단위의 분해능을 얻을 수 있으며 매우 근접한 측정 값입니다. 문제 공식을 식별하는 데에만 사용해야합니다. pane의 실행 순서는 DebugView에 선이 나타나는 순서에 따라 표시됩니다.
파일 이름 할당 및 TraceChartID () 코드의 맨 위에 배치해야합니다 또는 기본 포함 파일에 추가 할 수 있습니다. 이 함수를 호출하는 데 사용되는 단일 행은 각 창 / 창에있는 코드의 시작과 끝 모두에 있어야합니다. 이것은 DebugView에서 다음과 같습니다.
알 베노 사 편집.
2007 년 7 월 21 일.
실시간 지연.
실시간 거래에서 특정 기준이 충족 될 때까지 작업을 지연하려는 경우 많은 상황이 발생합니다. AmiBroker에서는 여러 가지 방법으로 지연을 지정할 수 있습니다. 단 하나의 요구 사항은 지연 변수가 증가 또는 감소한다는 것입니다. 선택한 변수가 시간 초과 값 (목표)으로 되돌아 가지 않으면 지연 기능이 절대로 시간 초과되지 않습니다. 이 경우 해당 조건을 처리하는 코드를 추가해야합니다. 몇 가지 변수를 사용할 수 있습니다 :
& # 8211; 경과 된 초 (재 작업).
& # 8211; 실시간 데이터 타임 스탬프 (TimeNum ()).
& # 8211; 볼륨 (볼륨 변경).
& # 8211; 가격 변동 (가격 변동).
& # 8211; 차트 새로 고침 (모든 AFL 실행).
위의 변수 중 지연에 사용할 변수는 거래 시스템의 요구 사항에 따라 다릅니다. 필요한 결과를 얻으려면 여러 가지 방법을 결합해야 할 수도 있습니다. 예를 들어 지연이 데이터 타임 스탬프를 기반으로 한 경우 데이터가 손실되거나 거래가 없을 때 시간이 초과되지 않을 수 있습니다. 이 경우 실시간 (초) 지연으로 데이터 타임 스탬프 지연을 백업해야합니다.
지연은 실시간 시스템 설계에서 중요한 역할을합니다. 예를 들어, 실시간 시스템에서 신호의 수명이 짧을 수 있습니다. 신호는 트리거 할 때 가장 강하고 몇 마디 후에는 모든 의미를 잃을 때까지 빠르게 사라집니다. 그것이 중요성을 잃었을 때 주문을 채우게하는 것은 순수한 도박입니다. 이를 방지하기 위해 지연 후 주문을 취소하거나 신호 강도의 감지 된 감쇠에 비례하여 위치 크기를 줄일 수 있습니다 (경과 막대에 따라 다름).
실시간 시스템에서 AFL 실행 간의 시간 경과가 중요 할 수 있으므로 LMT 가격 계산을 주문 코드보다 우선해야합니다. Calculating the LMT price after the order has been placed postpones order placement until the next AFL execution occurs, i. e., when the next quote arrives; by then, the price has probably changed. Especially during periods of low volume, this could be significant. When these delays would be insignificant in EOD systems, they could make-or-break your system in fast-trading systems.
To ensure frequent AFL execution in the absence of quotes, you can place a RequestTimedRefresh(1) statement at the top of your code, where the variable ‘1’ refers to a 1-second refresh. This guarantees an AFL execution at least once per second.
If your code is lengthy and takes a significant amount of time to execute, you may have to check order status at several places in your code. If changed status demands immediate action, you can force an immediate AFL execution by calling the following function:
July 14, 2007.
Preventing Repeat Orders and Whipsaws.
When you are developing a Real-Time trading system, often the first problem you have to solve is to prevent repeat orders. Repeat orders can occur when a signal remains true over several bars or chart refreshes, and each new bar/refresh sends out a new order. This can result in unintentional pyramiding.
Another ordering problem can occur when your entry and exit prices are too close together with respect to price volatility. In this case, the price volatility can whipsaw you in and out of positions in rapid succession. When this happens, slippage and commissions will quickly erode any profits you may have had. Also, if your system cannot keep up with each signal, you may end up in an opposing trade.
A common mistake when attempting to prevent repeat orders is to wait for order confirmation from the TWS after each partial fill. The problem here is that confirmations from the TWS are always subject to significant delay, and they will often let several repeat orders slip through before the acknowledgment is received.
Another flawed method is to filter or smooth the price arrays. Although this may prevent repeat orders, the lag introduced by this technique will kill most systems.
There is no single best way to prevent repeat orders. Your solution will depend on your personal preferences and the principle of your trading system. Under certain conditions you may want to combine several of the methods shown below. The examples presented here are intended to make you aware of the problems involved and suggest some possible solutions. It is your responsibility to modify the code to suit your particular system’s requirements.
To test the demo codes below, you will need to have the TWS running and connected to the IB eDemo or your paper trading account. To keep the programs below as simple as possible, you have to reset the programs after changing the Transmit ParamToggle from Off to On.
Using OrderIDs to prevent repeat orders.
When your program calls the PlaceOrder() or ModifyOrder() function, the IBc returns a unique OrderID. The OrderID uniquely identifies the order you placed so that you can refer to it later to modify, cancel, or check order status. The OrderID only acknowledges that the order was placed; it does not mean that the order was transmitted to the market or was filled.
If an OrderID has been received, this means that the order was placed. You can prevent order repeats by checking whether the OrderID has a value. Then, if you only place orders when the OrderID is empty, you cannot place repeat orders. The first example below lets you explore this procedure.
After an order has been filled or cancelled, you may eventually want to transmit a new order. In this case, you will have to define a rule for clearing the OrderID. This rule can be based on order status, a contrary signal, a time delay, the start of a new bar, or any number of things. Note that after you have cleared an OrderID, you can no longer modify or cancel the order it referred to. Hence, you should only clear an OrderID if you are sure that the OrderID is no longer needed, i. e., the order was confirmed cancelled, filled, or rejected.
The method below demonstrates how to use the OrderID, and because it still allows you to enter and exit (whipsaw) a position within milliseconds, it is only a first step to preventing repeats and whipsaws. To run this demo, Insert the code into a chart pane. When you open the Param window you will see these options:
The Chart Title shows IBc connection, OrderID, and Position status. Note that while Interactive Brokers calls all the messages ‘error’ messages, many are just harmless notifications. For more details on these error messages see API Error Messages.
When you click the Buy button, the Title will display the OrderID for the order placed, Order Status, and the position size if the order was filled. If you watch closely when you place an order, you may see order status change, for example from PreSubmitted to Filled :
In this demo you clear the OrderIDs manually. In a real system it would be cleared when your system is ready to allow the next order to go out.
Clearing OrderIDs at the Start of a New Bar.
In this example the OrderIDs are automatically cleared at the start of a new bar. This limits each type of trade (Buy, Sell, short, or Cover) to one per bar. If you want to place a new order while an order is pending, you may either cancel it first or modify the pending order.
Since the start of a new bar can only be detected when its first quote arrives, it is impossible to get a fill at this time. The earliest time an order can be filled is on the second quote of the bar. How long this takes depends on market volume and whether you use eSignal (trades) or IB data (snapshots). Since the Opening quote can occur at any time during the bar interval, it may take from zero to the full bar interval before the OrderIDs are cleared. To prevent this delay, you can clear the orders with reference to your system’s clock. However, this requires that your system is perfectly synchronized with the market-time (see next example).
The best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
The chart background will flash Green when a Buy order is placed, Red when a Sell order is placed, and White when a NewBar is started. You can test blocking of repeat orders by manually placing orders in rapid succession. The example code below will only place one Buy and/or Sell order during each bar-period (between White flashes). This method does allow you to take quick profits when both your entry and exit price are hit within one bar period. However you can do this only once per bar.
Clearing OrderIDs after a Delay.
This example maintains a delay between same-type orders. It uses a delay-timer for each type of trade and clears the OrderIDs when the delay times out.
If you set the delay to the bar-interval and if your system clock were synchronized with the market , then this method would give similar results to the NewBar method discussed earlier. However, this method is better since it enables you to place your LMT orders before the Open of the bar, thus giving you a one-quote timing advantage. This may not sound like much, but in fast trading, especially during moderate trading volume, this improves your chances of getting LMT fills.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Experiment with the parameter options and observe that you cannot place a same-type order before the delay has timed out (see Chart Title).
If your system trades LMT orders, you can design your orders to alternate between Long and Short without any limitations.
This method is well suited for reversal systems and high speed trading.
If your limit prices are set properly, this method will allow a fast sequence of reversal trades that can be very profitable. Systems like this may make several trades per minute, sometimes for several minutes, during high volatility.
In the following example, Order Status is checked, and an opposite order is only allowed to pass if the previous order has been filled. Note that this demo does not work if the Transmit ParamToggle is turned Off because under that condition no orders are transmitted to the market and can thus never be filled.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
알 베노 사 편집.
Comments Off on Preventing Repeat Orders and Whipsaws.
최근 게시물.
최근 댓글.
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.357 seconds.
No comments:
Post a Comment