我寫了一個警示腳本，來測試Summation(volume, 50)
這個腳本在測試時，都會發生不固定的"計算錯誤"，有時多，有時少，有時沒有。
請問小幫手，這個"計算錯誤"的原因是甚麼呢？
//Test.accumulated_volume_5
variable:v_accumulated_volume_per_minute(0);
v_accumulated_volume_per_minute=0;
if currentbar > 50
then
v_accumulated_volume_per_minute
= Summation(volume, 50);
"計算錯誤"的情形如下：
.jpg?width=690&upscale=false)
.jpg?width=690&upscale=false)
Sadless 您好
小幫手有幫您測試，
並確實也有這個問題，
此現象已經交由RD部門查找原因
有進一步的結果會再向您報告 感謝
Sadless 您好
主要的原因在於回測系統針對
Summation 這類需要運用迴圈去撈資料的函數
會有計算時限的機制，以防真的跑太久使得系統當掉or無限迴圈發生
我們觀看您的的回測報告發現回測時間滿長的且是1分k的情況下
所以資料量比較大
目前建議是: 請您先減少回測區間or回測量
我們也會思考如何優化系統，使得不讓這種情況發生
感謝
小幫手，謝謝你的回覆。
依照我之前的理解，XQ回測系統的時間能夠接受5分鐘的回測時間，超過會逾時。
但是這裡的回測只花了37秒，所以應該不是資料量的問題。
另外，如果是因為這些標的回測時間過長，那麼單獨針對這些計算錯誤標的做回測，應該也會造成"計算錯誤"，但是結果卻不會發生計算錯誤喔。因為每次發生計算錯誤的標的都不一樣。
我目前的實驗，有發現如果呼叫GetField函數越多，就越容易出現 "計算錯誤"的問題。
因為在分K的頻率， volume 是 呼叫 GetField("Volume","1")[0]，所以呼叫Summation(volume, 50);
等於是每分鐘呼叫50次的 GetField("Volume","1")[0] ，就會很容易出現"計算錯誤"的問題
我的猜測是，呼叫GetField 會需要向外面的資料庫伺服器要資料，但是如果中途的資料掉了，會造成資料不全，而導致計算錯誤，請問GetField有重送機制嗎？我們要怎麼確認GetField有正確的取得資料呢？
這個部分，再麻煩小幫手確認一下。
Sadless 您好
是的，您的推測基本上是正確的
這個現象並非5分鐘的回測時間這個限制，
而是系統針對會運用到「迴圈」的相關函數會令有時間限制
我們發現的問題也是因為這個限制而導致資料沒有抓取完全
所以發生錯誤
這方面我們接下來會放寬迴圈相關的時間限制
並再做後續的評估處理
感謝小幫手的回覆，原來是"迴圈"的強制結束造成了"計算錯誤"問題。
基於小幫手的回覆，我做了一個實驗驗證。
以下是我寫的測試用.警示腳本：Test.for.迴圈.計算錯誤
//測試用.警示腳本：Test.for.迴圈.計算錯誤
for value1=1 to 2
begin
value2 = 1;
end;
這個簡單的迴圈測試，的確會引發許多"計算錯誤"。
由於許多的腳本，都有使用迴圈，這個部分，再麻煩XS團隊解決。
回測結果如下圖：出現86次(失敗)，有85次計算錯誤，其中有一次錯誤也值得注意。
這個2247.TW(汎德永業) 的資料讀取似乎有問題，我從XQ只能讀取到這個標的一天的資料。
再麻煩小幫手確認一下。
2247.TW(汎德永業) 錯誤 資料長度不夠計算
.jpg?width=690&upscale=false)
Sadless 您好
2247汎德 2020/10/12 才上市喔!
所以過去沒有資料是正常的
回測功能並不支援興櫃的個股
原來如此。感謝小幫手的回覆。
這個現象並非5分鐘的回測時間這個限制，
而是系統針對會運用到「迴圈」的相關函數會令有時間限制
我們發現的問題也是因為這個限制而導致資料沒有抓取完全
所以發生錯誤
這方面我們接下來會放寬迴圈相關的時間限制
並再做後續的評估處理
這個部分再麻煩小幫手完成後回覆喔，感謝。
Sadless 您好
這個部份我們已有放寬了一些限制
請您有空時在嘗試看看
感謝
經回測，該回測已經沒有錯誤，感謝小幫手的幫忙。.jpg?width=690&upscale=false)
增加回測標的為全部上市櫃普通股，仍然測試成功。
真是太感謝小幫手的幫忙了。
.jpg?width=690&upscale=false)
分類
10 評論