現在的時間是 2016年 5月 5日, 10:50

[最新]   [熱門]  

    最新主題

  • 【日盛期貨-人民幣期貨結算價預測,丹堤美式豪華早午餐天天送!】 (2016/05/05)

    【日盛期貨-人民幣期貨結算價預測,丹堤美式豪華早午餐天天送!】

    活動期間:2015年5月3日~6月30日 8:45 ~ 14:00
    活動對象:日盛期貨或其交易輔助人之新舊客戶(不含特定法人客戶及員工戶)
    活動辦法:凡日盛客戶參加預測人民幣期貨結算價活動,每日預測值最接近當日結算價之前18名客戶,即可獲丹堤美式豪華早午餐乙套
    https://jsmarket.jihsun.com.tw/marketnet/marketing2016/FTR1602/index.html
    圖檔

    由 uuuu31 發表, 回覆: 0, 瀏覽: 8.
  • 為什麼 我認為,如果能很長一段 時間 產生 “CAROR/最差DD > 0.5”,你已經是很不錯的交易員了? (2016/05/01)

    為什麼 我認為,如果能很長一段 時間 產生 “CAROR/最差DD > 0.5”,你已經是很不錯的交易員了?

    為什麼 我認為,如果能很長一段 時間 產生 “CAROR/最差DD > 0.5", 你已經是很不錯的交易員了?

    這不是哲學面向的問題..............

    由 ptvisitor 發表, 回覆: 7, 瀏覽: 111.
  • 提高即時交易系統效率的方法 (4) – 「同步」與「非同步」委託的差異 (2016/04/28)

    提高即時交易系統效率的方法 (4) – 「同步」與「非同步」委託的差異

    在資訊商或券商所提供的下單API中可以使用提供「同步」與「非同步」兩種下單模式。
    例如,嘉實提供給券商(例如國票、富邦等大部分券商)的下單API中有SetEchoType函數,可設定API回傳值的方式為同步或非同步。
    何謂「同步」與「非同步」呢? 網路上的說法是:

    『使用「同步委託」在每筆下單時,會等 Server 回傳委託結果,然後才能委託下一筆;至於「非同步委託」,下單後,不等 Server 回傳委託結果,就直接丟下一筆單。「非同步委託」通常用在短時間連續下單時。若是「成交回報」,一定是「非同步回傳」,因為不一定會馬上知道成交結果(例如限價單)』

    我認為這樣的說法並不精確,以下提出一點看法提供討論。

    如前述, API 呼叫的回傳類型分為兩類:同步與非同步。
    若採用同步回傳時,呼叫會等API 執行完後,回傳完整資料。假如使用委託查詢,且使用同步回傳,則我們可以在程式碼執行階段知道我們此單是否委託成功,但是對於接下來要執行的程式碼(敘述3、敘述4),必須在第0.13秒才能執行。

    void 同步委託查詢
    {
    敘述1; // 0.01秒
    敘述2; // 0.01秒
    string result = 同步委託查詢; // 0.1秒
    敘述3; // 0.01秒
    敘述4; // 0.01秒
    }

    若採用非同步回傳時,呼叫API 後,COM 元件會產生一個Cookie,等執行完後,會執行Call Back Function,將結果傳回。
    此時再依照Cookie,將執行的API與對應的結果做結合。

    當使用委託查詢的非同步查詢時,則不等待確知委託是否成功,接續執行敘述3及敘述4,只要等待0.03秒即可。

    void 非同步委託查詢
    {
    敘述1; // 0.01秒
    敘述2; // 0.01秒
    string result = 非同步委託查詢; // 0.01秒
    敘述3; // 0.01秒
    敘述4; // 0.01秒
    }

    使用非同步查詢時,我們首先會收到下單API給我們的一個COOKIE,這個cookie的功能只是跟我們說你這筆委託查詢是否成功送到下單伺服器。等到下單伺服器處理完委託查詢要求後,傳回的完整資料,會經過下單API的處理機制判斷是哪一種查詢(下單、委託、成交),再送到另一個函式裡,所以完整的非同步實際上要有二組函式來做處理。即還要加上一段:

    void CallBackFunction
    {
    string result = Server回傳的完整訊息;
    }

    下單、委託查詢、成交查詢的非同步都是同一種機制。
    當「下單」使用非同步方式,收到的Cookie只表示下單伺服器是否有收到下單,不代表這筆單是「成功」或「失敗」,等到伺服器回傳完整的資料才能判知。
    當「委託查詢」使用非同步,收到的Cookie只表示下單伺服器是否有收到委託查詢要求,不代表這筆單是委託「成功」或「失敗」,等到伺服器回傳完整的資料才能判知。
    當「成交查詢」使用非同步,收到的Cookie只表示下單伺服器是否有收到成交查詢要求,不代表這筆單是交易「成功」或「失敗」,等到伺服器回傳完整的資料才能判知。

    依循以上的邏輯,何時使用「同步」或「非同步」就很清楚了。例如『後筆交易決策必須以前筆交易的結果來決定』就不能用「非同步」方式加速交易的進行。

    這一系列文章中,我們僅僅從交易系統內的軟體設計,討論提高執行效率的方法;
    事實上,加快執行效率的方法與面向很多,網友有興趣亦可參考6年多前,我在論壇與諸多網友的討論,

    viewtopic.php?f=25&t=750&p=2418#p2418

    viewtopic.php?f=25&t=750&p=2450#p2450

    我在『程式交易方法與實務應用』一書的第八章,談高頻交易的章節,則有更詳細的說明。

    由 clcy 發表, 回覆: 1, 瀏覽: 99.
  • 提高即時交易系統效率的方法 (3) – 以執行緒集區方法處理多工問題 (2016/04/28)

    提高即時交易系統效率的方法 (3) – 以執行緒集區方法處理多工問題

    在前兩篇文章(viewtopic.php?t=29076與http://www.programtrading.tw/viewtopic.php?f=10&t=29162)中提到,即時交易系統的瓶頸有時來自於上游取價端與下游下單端的Server。
    假若上游取價單的Server無法透過報價API元件提供「Server端主動報價」功能,或者下游撮合主機無法同時接受多筆下單訊息(或如FOK單無法接受多單交易),也只好在交易系統中『設法』解決。

    在另外一個個股期貨套利交易的系統中,我們遇到的難題是,系統同時監控多達207個股票期貨(以四月契約為例),標的可能『同時』出現套利訊息;最好的方式是套利系統『同時』向券商伺服器送出多筆下單訊息,但受限於券商模擬交易伺服器接收下單的方式,同一時間點只能接收一筆下單訊息,若任意丟單,將會導致系統出錯。
    為了解決此問題,我們只好限制系統丟單方式,自行對於套利機會排隊,統一由一個下單系統送單,這樣雖然解決同時送單的問題,也降低了下單的速度,使套利機會減少。
    這顯示交易系統開發受制於遠端撮合系統的設計,對於高頻交易是另一個瓶頸;如果是自營單位進行高頻交易,單子直接往交易所丟,就可以跳過這個瓶頸,證明了諸如套利的高頻交易形式,對於自然人是不利的。

    執行緒的概念在前一篇文章(viewtopic.php?f=10&t=29162)已經介紹,在此進一步延伸。
    在執行緒相關概念還沒發展前,作業系統執行工作的方式以類似『循序』的方式執行,也就是同一個時間只能做一件工作,為了改善這個問題,便有了『處理序』(Process)的概念與做法。
    『處理序』類似於我們一般所了解的應用程式,譬如Word、Line等,其工作模式類似於多工。每個處理序在記憶體上的位置為獨立的空間,彼此互不干擾,所以如果當某個處理序(或稱應用程式)出錯或掛掉時,也不會影響到其他的處理序。
    雖然處理序在記憶體間互不干擾,不過負責運算的CPU卻是共用的,也因為共用CPU的關係,當某個處理序進入無窮迴圈時,CPU便無法處理其他處理序的要求。造成類似當機的情況。為了解決共用CPU的問題,便產生『執行緒』的概念。
    『執行緒』的概念類似於虛擬的CPU,一條處理序等於一顆CPU。系統會為每個處理序配發一條專用的執行緒,因此,就算當某個處理序進入無窮迴圈時,其他處理序仍可以繼續運行不受其影響。如果在一個處理序裡有多條執行緒的話,則稱為『多執行緒』,譬如影片播放程式,使用者可以在程式讀取影像資料看到畫面時,也可以同時聽到聲音或設定畫面大小。
    執行緒可以在提高程式回應速度的同時,也可以處理好工作所需要的資料,提供較佳的使用者體驗。
    根據MSDN對執行緒建議,其使用時機如下:
    1. 需花費較長時間才能執行完畢的工作
    2. 修改工作的執行順序
    3. 保持程式的回應性
    4. 希望某工作可以長期被執行而不影響系統

    執行緒缺點是太多的執行緒會造成記憶體的消耗、增加處理器的運算時間以及編碼的困難。因此有了『執行緒集區』的做法。
    『執行緒集區』(Thread Pool)也是套利系統中重要的技術。在執行緒的優缺點及使用時機裡提到,執行緒大部分用在『長期』的工作上,也因為開啟、結束執行緒需要付出額外的成本,所以不建議開啟太多的執行緒造成資源的浪費而影響效能,因此,C 語言中提供『集區』(Pool)的概念與功能。
    『執行緒集區』概念類似執行緒,不同的是他是一群執行緒的集合。當集區收到工作請求時,系統會在集區裡搜尋閒置的執行緒,並將工作分配給該執行緒,當該執行緒完成工作後,他會回到集區裡,等待下一次的工作分配,而不是被摧毀,進而減少因重複建立與結束執行緒所造成的資源浪費。
    當工作請求過多時,系統會決定是否要增加新的執行緒至集區裡,以應付增加的工作量。當工作量減少,不需要用到這麼多的執行緒時,執行緒會被摧毀,以釋放記憶體資源。

    因此,如果一任務所需要的工作時間較短,且可能會頻繁建立及結束執行緒時,可使用執行緒集區來替代專屬執行緒。

    由 clcy 發表, 回覆: 1, 瀏覽: 97.
  • 提高即時交易系統效率的方法 (2) – 處理多標的同時下單問題的方法與困難 (2016/04/27)

    提高即時交易系統效率的方法 (2) – 處理多標的同時下單問題的方法與困難

    前一篇文章(viewtopic.php?t=29076)提到,取得市場報價方式,若從「Client端主動詢價」轉為「Server端主動報價」,可以提升交易系統的效率。

    只是不同券商或資訊商提供的API不具備「Server端主動報價」的功能函數,或者僅針對期權商品提供Server端主動報價;即使API手冊中提到有提供Server端主動報價的API函數,仍然要經過實測才能確認。我目前與學生進行的『可轉債(CB)套利系統』實測系統建構研究,在使用的嘉實報價API手冊中,雖有提到股票可以做「Server端主動報價」,但實測上卻做不到,因此在該項研究中只好退而求其次以Timer控制項定頻透過API函數做「Client端主動詢價」。

    對於CB套利而言,這不成問題,因為台灣證券交易所的股票交易仍然採取集合競價方式,每5秒鐘進行撮合、提供委託簿報價。相對而言,對CB套利,我們更希望資訊商的報價API能夠取得各券商可放空券源有多少,以及告知系統近期有無股東會或臨時股東會召開,以規避可能打亂CB套利節奏的標的。

    至於期權市場的系統,如果是單一商品的投機系統,例如台指期的日內定頻K線或逐筆交易系統,前述「Server端主動報價」的功能也就夠了。但若是多商品組合的套利策略,可能就會遇到其他的難題。

    我們的另一項研究—「選擇權價差組合套利」,面對逐筆撮合的選擇權市場,除了必須採取「Server端主動報價」的方式,還遇到另外的問題 — 如何『短時間同時建立4個選擇權部位』以及如何『有效率同時驅動多組選擇權套利模式』。這篇文章,我們談談目前遇到的困擾與解決方式。

    首先解釋一下『選擇權價差組合套利』,此類套利由選擇權『多頭價差』與『空頭價差』,組合成『盒狀價差』(兩個不同履約價的價差組合)、『蝴蝶價差』(三個不同履約價的價差組合)與『兀鷹價差』(四個不同履約價的價差組合)。由於多頭與空頭價差可以由高低履約價的買賣構成,因此計有12種組合方式。目前台指選擇權市場可以交易月選擇權與週選擇權,因此組合數更多。
    若以月選擇權的『盒狀價差套利組合』為例,假若使用5個履約價進行組合,可以組合成「C 5取2」種組合;若是蝴蝶價差,可以組合成「C 5取3」種組合;若是兀鷹價差,可以組合成「C 5取4」種組合。假若履約價範圍擴大,則組合數越多,週選擇權的履約價跳動點為50又比每隔100點產生履約價序列的月選擇權還多。
    在我們的實測中,當價差組合中任意一隻腳(履約價)有價格變動,由「Server端主動報價」通知,啟動組合運算,平均一個交易日會測試376萬種套利組合,從中尋找無套利機會;在流動性較高的交易日,最多一天可到550萬種組合的測試。

    套利機會發生於當市場相關商品產生無效率交易報價時,機會只有一瞬間,為了在分秒必爭的情況下,確實搶到有獲利機會的少數委託報價,在系統的架構上必須採用多工的方式(也就是多線緒技巧),才能有效壓低各策略運算判斷時間,確保套利者在市場上可以確實地搶到因報價無效率產生的少量報價單。因此,在系統建構時,我們使用『多線緒』的技巧,除了用以壓低運算時間且能針對重複性的工作進行簡化,大幅地降低在程式設計上的難度及設計時間。

    何謂執行緒與多線緒? 在此簡單說明。『執行緒』使用作業系統虛擬化切割 CPU 的想法,給予每一個處理程序配與一個專屬的執行緒,每一執行緒功能近似於獨立 CPU,以達到多工效果,而『多線緒』為執行緒衍生的技巧,只要使用多個執行緒就為多線緒。一般程式在運行過程若沒有特別宣告或開啟多線緒指令,程式運行的過程中就如同一單線道路,當資料量過大或運算時間過長時,後續的資料無法插隊優先運算,所有進入程式的資料都會依照先後順序排隊。但因本研究所處理的套利系統必須搶時間且同時讀取眾多不同商品即時報價,無法容許各個系統程序運算時間過長,因此在速度提升上做了特殊設計。

    本系統之報價資料取自嘉實資訊的報價API,因委託簿每秒鐘內會有數筆逐筆(Tick)資料,需要對每筆資料進行組合運算,在抓取商品報價時必須運用前述多線緒技巧,讓每一個商品報價都有專屬執行緒,避免程序衝突及資料錯誤等結果。
    此外,為了避免策略運算過程中占用電腦的主執行緒,所以系統在接收最新報價後,會同時建立一條專屬執行緒,用於當前最新報價之策略運算,以解決主執行緒佔用問題。
    最後,在解決了策略運算過程大量執行緒問題後,因為只有一個輸出視窗,無法同時接收來自各執行緒的運算結果,為此,使用C#內建『Lock』語法,讓來自各執行緒的結果依照進入時間排隊,避免資料錯誤或遺失。

    但有些限制(瓶頸)並不在Client端系統設計上,反而是發生在承接下單的Server端,與我們配合的券商的FOK單(Full or Kill;全部成交否則取消)單,只能同時下2種商品,因此要同時建立四個部位會有時間落差,產生瞬間風險。

    由 clcy 發表, 回覆: 13, 瀏覽: 281.
  • 程式交易方法論
    有關於程式交易方法論、心得、想法等智識性討論,可於此分享。
    490 主題
    3168 文章
    最後發表ptvisitor 檢視最後發表
    2016年 4月 13日, 11:11
  • 金融交易讀書心得和程式交易模型報告
    若您讀過與金融交易相關的專書或文獻,可在此交換心得。或若您有好的交易模型也可在此分享模型內容與績效報告。
    136 主題
    796 文章
    最後發表qyliaowei 檢視最後發表
    2016年 4月 30日, 12:35
  • XS、TS、MC、TB交易平台討論
    有關於XS、TS、MC與TB等平台程式碼撰寫、績效評估等疑難雜症,都可在此討論。
    410 主題
    1901 文章
    最後發表jack810514 檢視最後發表
    2016年 4月 27日, 10:29
  • Excel VBA、VB、VB.Net交易平台
    有關於DDE使用、泛VB策略撰寫、績效評估等疑難雜症,都可在此討論。
    261 主題
    1518 文章
    最後發表Byron 檢視最後發表
    2016年 4月 26日, 11:17
  • 其他交易平台(C#、Wealth-lab、Matlab...)
    有關於其他平台、使用、策略撰寫、績效評估等疑難雜症,都可在此討論。
    92 主題
    885 文章
    最後發表hikingplooo 檢視最後發表
    2015年 12月 4日, 21:37
  • 下單API應用
    有關API應用、下單流程最佳化、下單機、演算法交易等,都可在此討論。
    98 主題
    595 文章
    最後發表test1 檢視最後發表
    2016年 5月 4日, 18:13
  • 理財規劃與財富管理
    舉凡關於理財規劃、資產配置、風險管理(包括保險)與金融行銷等主題,均可在此討論。
    76 主題
    230 文章
    最後發表uuuu31 檢視最後發表
    2016年 5月 5日, 09:19
  • 財務工程與金融創新
    舉凡關於財務工程、金融創新與金融商品分析等主題,均可在此討論。
    29 主題
    113 文章
    最後發表clcy 檢視最後發表
    2016年 4月 5日, 08:26
  • 綜合應用分享
    除了程式交易,資訊技術可被應用在其他金融領域,您可在此分享心得
    375 主題
    2527 文章
    最後發表sean770804 檢視最後發表
    2016年 5月 4日, 14:53

登入  •  註冊

誰在線上

線上共有 4 位使用者:3 位註冊會員、0 位隱形會員和 1 位訪客 (這些資料是根據過去 5 分鐘內使用者的活動記錄)
最高線上人數記錄為 148 人 [ 記錄時間:2012年 7月 10日, 00:33 ]

註冊會員: Bing [Bot], Google [Bot], Majestic-12 [Bot]
顏色說明: 管理員, 全域版主

統計資料

文章總數:11784 • 主題總數:1974 • 會員總數:27770 • 最新註冊的會員:husonchow