微信：
QQ：
MultiCharts编程中幽灵信号不是谁的错
這個所謂的幽靈訊號指的是盤中曾經出現但盤後卻消失，或是盤中沒有出現盤後卻出現的交易訊號。我們撇開那些程式碼本身就存在著邏輯結構的問題，最顯而易見的像是 This bar at XXXX stop/limit 或是 判斷條件同時滿足多空 這類以外之後，其實絕大多數的幽靈訊號是來自報價資料傳輸的問題。國內使用DDE作為報價資料傳輸的朋友我相信還是佔很高的比例，原因不外乎就是取得方便而免費，然而我不是要批評DDE不好，雖然在報價速度加快的時候(快市)，DDE丟三落四早已經是正常現象而不是新聞了。實際上，除了你有那雄厚資本把自己的電腦放在期交所的主機旁邊，插根吸管讓期交所給你喝第一口的瓊漿玉液外，所有的成交報價資料(Ticks)，到達我們放在家裡或是公司的電腦上時，其實已經經過好多手了，TCP/IP的網路架構本來就是如此，而且報價的封包在網路上傳送是有壽命的。
我們自己的電腦接收的報價資料盤中或有錯漏其實是不可避免的風險，就算你跟期交所拉專線，它都不保證絕對 OK 咧！而交易策略訊號的產生是建立在 User 這端的歷史資料(除了當下都是歷史)上，所以如果接收的報價資料有了錯漏，而日後(盤後)哪天你去修正補足資料的話，那這所謂的幽靈訊號出現，我想就是在自然不過的事情了，而這幽靈訊號其實不是你我的錯，只是環境如此啊。
甚至，有人把同一個交易策略平移到不同的交易平台上去 Run ，也會看到一樣的策略卻有不一樣的訊號，這...也是正常的 >"< 的啦。為什麼呢？不同的交易平台對於把 Tick 堆起 K棒的方式其實或有不同，這造成不同的平台的 K棒的 開高低收及成交量都有可能不一樣，誰的對？沒有誰對，因為交易所從來沒有提供過 K棒的資料，它只提供一筆一筆的成交價與量而已，沒有 K棒，K棒是我們自己標定而畫出來的。因此，一人一把號，各吹各的調。 舉例來說：在 MultiCharts 上，2011/05/09 的 Tick 資料最後一筆有時間在 134500的，你可以自行到期交所的下載回來看看。
[attach]5355[/attach]
在行情資料庫 QuoteManager 裡也可以查得到，這表示 MultiCharts 是有接收到這筆報價資料的。
[attach]5356[/attach]
但是，在 MultiCharts 的 K線圖上有這筆報價存在嗎？沒有耶～這是因為它的堆 K棒規則把這筆資料排除了。這使得 05/09這一天分線圖的最後1根的收盤價成為 9065，而不是 9063(我們好像都認為這天的收盤該是9063？)，而這有什麼問題，有時候巧合就是會發生，同一個策略 on MultiCharts：
[attach]5357[/attach]
on HTS：
[attach]5358[/attach]
一個價格的影響在其位置也許就造成某個交易策略後續的一連串動作，即使到了今天，這個策略在兩邊的平台上都會是空單留倉，但也有著部位大小的不同，那我該說哪一邊是幽靈訊號？
結論：除了不同平台的堆 K棒規則所造成的開高低收這些數據差異而造成的訊號差異之外，盤中的資料傳輸也會有錯漏。改善方法：一是讓你的軟體常常盤中做 Data reload，這是假設資訊供應商的設備比我家的好，他們主機上的資料應該比我的好，所以我在盤中做 Reload，如果過去的一段時間我這邊接收的資料有錯漏的話，希望能在盤中即時得到糾正；二是花錢買更好的資訊來源，降低盤中資料接收錯漏的程度，甚至還為此添購更好的資訊設備，比如有封包錯誤檢查能力的網路卡～
理論上來說，這些某個價格的影響在策略"長期"的績效表現應該會是很小的，的確，兩邊的平台回測資料看來也不是差異很大，只是～你知道，當發生的時候我們都想挑好的那邊。幽靈 K線無所不在，了解其原因，接受這個事實，同時也因此知道有些事情我們真的是無能為力的。比如：想從事 Tick trade？嗯，我的設備夠好嗎？ 感谢分享，学习学习
页:
[1]