外接下單機的結算日清倉實作

：程式交易小學堂─期貨投機事業的王道

我在台指上的交易，讓交易策略每到結算日就收盤清倉的作法，已經維持數年。
僅用 if _checkDay then setexitonclose; 一句來達到訊號的回測。但是，這樣的寫法是不能直接用在日常實戰的。我自己不用內建下單機，不知道她會怎麼動作？而外接下單的方式，則因為單純這樣的策略內指令不會在結算日的收盤前有任何圖表訊號出現，所以也就不會輸出部位變化給外接下單機知道。因此，實際上是根本沒有任何的平倉動作，讓交易所把我的部位給結算掉，而得到真實清倉的效果。

但是，因為外接下單機沒有接收到任何的部位變化訊息，它也就不會有任何動作，從而在結算日收盤後變成錯誤的帳上留倉部位，這會導致後續的交易錯誤。因此，我必須在結算日這天的收盤後，採用手動或自動的方式，讓外接下單機上的帳上留倉部位（下單大師稱為"實際倉位"）給歸零。

這裡提供一個方式，讓外接下單機可以知道我要在結算日這天清倉：把輸出給它的資訊，強迫改成... ０。

在你要輸出到外接下單機的訊號或是指標中做這樣的寫法：

var: IntrabarPersist MP(0);

{MP 是要輸出給外接下單機的部位數值，因為我要他在結算日的收盤後做變動，但當時會沒有 tick 進來，所以要宣告成宣告成 IntrabarPersist ，好讓我變更這個變數的數值後得以保留，不會被回復。}

if CheckDay and ( currentTime<0845 or currentTime>1340 ) then

  MP= 0

else

  MP= i_marketposition * i_currentcontracts;

{這一段是判斷 K棒是否屬於結算日，並且如果電腦時間在 08：45 前 或 13：40 後的話，把 MP 設為 0，其他時候則 MP 就是本來你要輸出的訊號部位。這裡需要想像一下，CheckDay 的結算日判斷，是以 K 棒的日期作為判斷的依據，所以當今天是結算日的話，是從開盤第一根K棒就開始回報為 True，所以要限制它必須電腦時間在 13：30（結算合約的最後交易時間）之後才可以變成 0。而當結算日收盤後一直到隔天的早上開盤前，因為沒有新的 tick 進來，不會有新的 K棒日期出現，所以就圖表來看這一段時間，函數 CheckDay 回傳值都會是 True，加上電腦時間在 08：45 之前也算（以防你的 MultiCharts 與下單機都一直開著沒有關掉），就讓結算日的 13：41～ 隔天的 08：45 前，把 MP 指定成 0 的條件都成立}

RecalcLastBarAfter(1);

{這個指令是為了在沒有 tick 的時候，強迫這個訊號或指標的 code 都每秒 run 一次，透過這個指令，才能在 13：41 開始，把 MP 從原本的部位數值變成 0，輸出出去給下單機接收到，也因為這個變化是在沒有 tick 進來的狀況下，不可能會有換 bar，讓一般的變數值更新，所以才需要把 MP 宣告為 IntrabarPersist}

透過這樣在負責輸出部位數值給外接下單機的訊號或是指標，就能夠在 13：41 的時候讓下單機知道部位應該要變成零，而去執行下單的動作，雖然當時的委託送出其實是會失敗的（非該商品的交易時間），真實部位一樣進入結算，但下單機內的帳上留倉部位卻會歸零。我也就不需要另外手動去調整下單機內的帳上部位了。

K棒是否屬於結算日的判斷函數（CheckDay）請見：http://www.yctseng.net/2012/03/blog-post_13.html

帳戶管理人的必備工具

：程式交易小學堂─期貨投機事業的王道

在 Blog 每日公佈個人交易帳戶的權益變化好些年了，我也承認在那個帳戶中其實有不少交易並不是程式交易下單的。因此，有些時候看到我的帳戶績效衝得比較快也不見得是程式的功勞。事實上，人為主觀下單更多時候給我的帳戶績效帶來的是負面影響，但我還是難逃想要自己下場交易的誘惑。

然而，在我管理的受託帳戶就完全是程式交易的下單，主因是我無力同時照看多個帳戶。好險，這個因素讓我得以在受託帳戶上實現完整的程式交易實單記錄。

即使知道使用「智能交易顧問 SmartCTA」，在真實交易經驗上確實有效，但它卻無法提供回測，可...大家都是回測控啊！我一直說 SmartCTA 有效，但它到底是怎樣的有效呢？空口白話總是很難體會。因為我有真實的記錄資料，就來做個比較給大家參考。


以下這三個帳戶，分別記錄不同開始時間，不同的資金規模，但都使用相同的訊號組合來源(可每日查看)。

策略管理機制的驗證：Random equity

：程式交易小學堂─期貨投機事業的王道

前文說過，KPI 只是整個管理系統的起點，因為所有的管理動作，都必須有"衡量"，而且是一致化、量化的衡量，不是隨個人喜好的衡量。

然而，我們會想出各種可能的 KPI，也可能因而衍生出各種不同的管理動作流程。這時，另一個問題就出現了：哪一個有效？又誰比誰更有效？有效又是表現在哪些面相？在每天的真實交易績效表現上，這是我們時刻要面對的，絕不能僅僅只是認定它有效就帶過。

券商版MultiCharts讀取文字檔的函數製作

：程式交易小學堂─期貨投機事業的王道

因為要讀取文字檔，需要用到外部的 DLL 來完成。一樣的，這會使用到被 券商版-MultiCharts 攔截的關鍵字，所以操作流程與原理，跟之前的教學是一樣的：讓券商版 compile 一個函數出來，建立好內部的連結，再使用專業版 compile 過函數而產生的 dll（實際上的動作執行者），覆蓋掉券商版內的 dll，把實際的動作執行者，來個狸貓換太子。喔，不～是太子換狸貓 XD

這次示範所用到的函數程式碼就是舊文中的內容：http://www.yctseng.net/2015/07/elcollectionsdll.html

券商版MultiCharts也能調用外部DLL

：程式交易小學堂─期貨投機事業的王道

一些 專業版-MultiCharts 能做，而券商版不能做的事情，除了圖表數量限制、投資組合回測外，最重要的就是在編輯程式碼之中，幾乎把要對外聯繫的關鍵字都給切斷了。這一篇就是教你，如何讓你的 券商版-MultiCharts 重新取回對外聯繫的能力。當初獲知的知識來源：http://www.coco-in.net/thread-15559-1-1.html

這個範例是以呼叫 DLL 的方式來做文字檔的輸出，同理，只要你拿到或著自做讀取文字檔的 DLL，甚至連接自己的資料庫，只要透過 DLL，都可以照樣套用，讓你的 券商版-MultiCharts 能對外寫入、讀取檔案，光是對外部的文字檔做讀與寫，就能創造類似資料庫的效用了。

本範例使用了凌波微步大分享的 outputfile.dll，我放在 C:\AutoTrading\ 下供 MultiCharts 調用。

我建議，當你需要做這樣類似 "越獄" 的功能，都以「函數」優先，因為在任何指標、訊號、函數要呼叫其他函數的的程式碼編譯，券商版編輯器是不會往前追查去攔截關鍵字的。

函數（_OptimalF）：Optimal F

：程式交易小學堂─期貨投機事業的王道

說起資金管理，大約都會耳聞過 Kelly formula，也會聽過它其實用在交易上的問題很大。後來有以 Kelly 精神生出了 Optimal F。而它的來由與計算方法，我就不多贅述，請自行參考：牧清華的文章。

要把 Kelly formula 寫成 MultiCharts 函數在策略中或是其他引用，算是一小片蛋糕。這一篇要分享的是，我一開始看了牧清華介紹，覺得計算很麻煩的 Optimal F。

交易管理的源頭：圖表績效KPI

：程式交易小學堂─期貨投機事業的王道

論述、講課了幾年後，最近，總算感受到台灣程式交易圈，交易是需要建立管理系統這個觀念，漸成顯學之勢。在交易管理系統中，對策略圖表的績效評分就是所有管理行為的源頭，先有了策略績效的評分，才以策略績效的評分作為資金分配的對應動作。

我與認識的友人絕大多數都是做順勢的投機交易，很習慣的把商品走勢本身的波動就等於策略是否能賺錢的等量指標。事實上，我認為這是錯誤的連想。就算商品價格真的有一個波段走勢的出現，你有沒有看過原本設計為順勢波段的策略卻是虧損的？當行情看似箱型、旗型整理、甚或大小喇叭走勢，自認為順勢波段的策略卻獲利了？如果你也有過這樣的經驗，就該回頭想想，商品價格本身的走勢類型，真的是能直接連動你的策略績效嗎？很明顯的，不是。過去，我們習慣以商品價格本身的波動來衡量風險的大小或利潤的預期，現在我認為，這樣的想法問題很大！