這幾天收到一個網友來信交流，請教我六個問題，同時我也回覆了。
徵得網友同意後，我想把這六個問題其中五個，分成五篇文章也同時和大家分享。
2. 您認為哪種語法最適合拿來建構交易策略的建構與回測？
信中回覆：
我覺得這很看情況，當然如果你有特殊的演算法，需要特殊的分散式計算，然後演算法又需要種種靈活性
可能你算完直譯的語言（如 Python）會比較好，整體開發成本、團隊維護成本、環境成本可能比較低
所以我說很依賴情況，如果在這些條件都是未知的話，也沒有過多的包袱的話
我認為編譯型的語言比較好，因為的確執行速度比較快
這部分很重要就是你要觀察掛單到執行的時間，和你公司的成本
通常來說掛單到執行，整個順序有三步，
(1) 送出掛單 (時間 1)
(2) 接收到掛單然後回傳告訴你收到了 (時間 2)
(3) 回傳告訴你掛單成功/失敗 (時間 3)
如果你沒有刻意追求速度快（通常機構才有辦法追求快）
你大概在時間 1 + 2 + 3 上面大概需要花 1.5 秒
2 和 3 有時候會重疊，但是在 2 的時候你可以先做準備動作，預防 3 的失敗，也就是大約 1000-1500 ms
先不論交易訊號，演算法那些，畢竟那些的頻率不會那麼高
所以 關鍵是策略出狀況，你的 Error Handling 的速度
也就是你從問題恢復過來的速度，這個問題恢復的速度
可能就代表你需要採取一堆掛單、改單、撤單的操作，不斷丟 action
這部分要能在非常低時間延遲下完成，我覺得非編譯型語言很難
我目前認知到我想像中的那種完備的 Error Handling
大概在 Python 或一般平台上面，都要花 2-5 秒的時間，才能全數執行完畢
當然這是我目前腦中的，你不知道我在想什麼，反正就是很完備
部落格補充：
我對 Python 不熟，至少以我一個門外漢用簡單的 Socket
是無法達到我想要的需求，所以前面這段純粹是我以我狹隘的經驗出發的結論
在信件中我沒有特別談 Error Handling 的細節
是因為這邊的 Error Handling 通常是一環扣一環，而且可能需要重複不斷驗證
也就是我會假設 Error Handling 是在一個會不斷 斷線/恢復的 低效情境 執行的情況
直到我某一個 Step 成功，我才會往下走下一個 Error 應對的 Step
這邊的 Error Handling不是說我另外再開一條線去從旁做輔助
而是在原本就出狀況的交易策略執行中，直接採取一些防衛機制去避免 Error
所以我除了原本策略需要跑的東西外，我還要不斷被耽誤去救可能有發生的 Error
這部分如果不能非同步 Asyc, 就需要花費很多時間
在我狹隘的個人使用 Python 的經驗中，可能會太久，超過 2000 ms 就很危險了
但我的 Python 經驗非常皮毛而且非常古老就是了..... 所以 ?
我也不知道 XD 我只能照經驗回答
沒有留言:
張貼留言