回測結果異常（腳本參數不變的情況下，無法回測足夠長的時間）

  •   835 
  • 最後發表   iker  2023 二月 08
iker 發文於   2023/01/07

我有一套腳本去回測  60分K 的小台近月期貨時，用了以下三個時間範圍回測，發現結果有點問題：

1. 2022/07/06 - 2023/01/06 （半年）
2. 2022/01/06 - 2022/07/06 （半年）
3. 2022/01/06 - 2023/01/06 （一年）

當我回測第 1、2 兩種時，都能看到有正常觸發交易的紀錄，但回測第 3 種時，跑出來的交易紀錄跟第 2 種完全一樣，沒有後面的交易紀錄...

回測是用相同交易腳本、完全不改變其他參數的情況下，只是選了不同回測範圍的結果。

想請問 60分K 要怎麼回測 1 年以上的資料？

另外第 1 種回測結果裡，我有使用以下方式寫期貨結算日平倉的條件，這段程式碼用在同樣策略的指標腳本裡，畫在指標上確實有按結算日出場。但交易回測並沒有正常出場，導致裡頭的編號 1、13 的交易持倉天數超過了期貨近月的天數。

if DayOfWeek(date) = 3 and DayOfMonth(date) > 14 and DayOfMonth(date) < 22 then
SetPosition(0, Market);

請問要怎麼改才能在交易回測時按結算日出場？

排序方式: 標準 | 最新
XQ小幫手 發文於   2023/02/08

Hello iker,

 

會修改的是以下三個函數：

HVolatility

BlackScholesModel

linearreg

 

問題是在該函數變數宣告賦值的方式，如 variable: SumX((Length* (Length+1))/2); 。

這種宣告方式，如果後來 Length 的數值改變了，接下來腳本的運算 SumX 並不會改變，因為 (Length* (Length+1))/2 只有在該變數宣告的時候運算。

iker 發文於   2023/02/07

了解了，感謝解惑～

XQ小幫手 發文於   2023/02/07

Hello iker,

 

您回測的腳本中有使用到系統內建的函數，有問題的是這些函數腳本。

而這些函數腳本在本機端和伺服器都存在著，目前是將伺服器端的修正完畢。

至於是那些函數出現了問題，小幫手需要和相關人員確認後才能回覆。

iker 發文於   2023/02/03

Hi 小幫手

感謝協助排查

不過有點聽不懂您所指的內建腳本，想請問這是指server端收到請求時，處理回測必須運行的特定腳本嗎？

還是您的意思是我的腳本裡用到的特定系統內建函式會造成這個問題？如果是這個情況，方便告知是哪個函式會有問題的嗎？

XQ小幫手 發文於   2023/02/02

Hello iker,

 

經相關人員確認，您的問題是因為有些內建腳本撰寫上出錯所導致。

目前伺服器的部分已經更新完畢，所以現在重新回測已經不會發生問題。(參考附圖)

本機端的部分則是預計在近一次改版中更新。

附加文件

XQ小幫手 發文於   2023/01/18

Hello iker,

 

小幫手這邊會請相關人員確認看是否能找出原因。

感謝。

iker 發文於   2023/01/15

另一個警示腳本前兩天回測都正常，連續回測都能得到相同結果，但在昨晚稜凌晨2點開始， 一直到現在每次回測結果都不同。

一樣是參數不變、回測範圍不變，停損利也不變。

已經將LOG、腳本、回測報告寄到信箱，麻煩看看是什麼情況造成連續送出後、得到完全不同的回測結果

iker 發文於   2023/01/13

感謝回覆

XQ小幫手 發文於   2023/01/13

Hello iker,

 

您的這個問題是出在腳本撰寫上，和系統運作比較沒有關係。

所以並不需要檢查 Log，小幫手和您要Log只是確保如果問題是和系統設定運作有關的話，不需要額外再跟您要求相關資訊，減少花費的時間。

只要在腳本下方加上 print(date, time,direction, hasPosition); 您就可以看到回測2022/01/06 - 2023/01/06時在 4/27 以後印出的 direction 跟 hasPosition 都會是 -1.000000 FALSE 。

這就會讓腳本不再進到交易判斷式裡面。

造成這個狀況的原因就如同小幫手上面回覆所說。

 

關於 SetTotalBar 的部分:

跟LinearRegAngle沒有關係，是EMA(close, 120)計算出來的值會出錯。

您可以實際把EMA(close, 120) print 出來和指標上面比對，就會發現兩者不同。

而這是因為EMA在運算時會取前期的值來做運算 (ex. EMA = EMA[1] + Factor * (thePrice - EMA[1]);)。

所以需要經過一定期數的運算，得到的值才會和技術線圖相同，這個所需期數大約為EMA長度的4倍。

如果您覺得消耗資源的話，或許可以改為計算移動平均 (average)，這樣就不必設定那麼長的期數，因為average在運算時不會取用前期值。

iker 發文於   2023/01/13

Hi 小幫手

感謝回覆，我再試試看。
（昨天有手動排除掉一些多餘的log，附上壓縮過Log檔連結寄到信箱了，也再麻煩你們確認一下是不是你說的這個問題。）

關於用到移動平均條件需要設 SetTotalBar 長度的問題有點不太懂:

1. 請問是因為斜率取了 4 期，所以需要取至少 4 倍才能算出正確數值嗎？
2. 如果 SetTotalBar 只設了 120，這樣斜率運算的前三期系統默認會是帶入什麼值去計算呢？直接把資料長度不夠的部分視為 0 嗎？
3. SetTotalBar 加長會很吃計算效率，加上我只需要當下運算的斜率，並不會參考前 n 期斜率，改成設 SetBarBack 設 120 * 4，SetTotalBar 設 1 能取代直接加長 SetTotalBar 嗎？

 

 

顯示更多回應 發表回覆
發表新主題
我的發文
我的收藏
分類
Close