張貼日期：Aug 16, 2018 9:50:42 AM
GMDS的PatsEmu-CME從2015的 v2 Template 設計後運作到現在,
期間CME已經改版多次到上次的v8, 其中有幾次還造成路透的系統突槌...
反觀GMDS卻無須任何配合修改, 一值完全正確處理資料
不過這次的v9已經不是格式修改, 而是整個翻新,
分析其主要目的為將小數7位的定義擴大到9位
這個動作其實早在估計之內, 於最初解v2資料時就已經覺得設計上有問題,
無奈下游只能配合, 不過有覺悟的話至少還是預先參數化讓程式比較容易逢變時擴增
為什麼會有這種預感呢? 因為英鎊計價的部分都是分數
1/256 = 0.00390625 其實就應該已經用到小數8位了
當我們透過通分時, 雖然分母 3200 似乎夠用,
但實際運算時 3200/256 = 12.5 尚未整除,
所以實際以整數處理時會擴大到使用分母 6400 來處理
反之 6400/12.5 = 512 也就是逆向處理時, 用 1/512 作為邊緣較為合適
1/512 = 0.001953125 那麼就會使用到小數9位了
本次的主要變動:
■多了 PRICE9 和 PRICENULL9 的新欄位定義, 用來替代原本的 PRICE 和 PRICENULL
■多了 Decimal9 和 Decimal9NULL 用來替代原本的 FLOAT
■新增以下格式 (都是有套用到新欄位而變更)
MDIncrementalRefreshBook46 id="46" ==>取代原使用的 MDIncrementalRefreshBook32 id="32"
MDIncrementalRefreshOrderBook47 id="47" //行情沒用到
MDIncrementalRefreshTradeSummary48 id="48" ==>取代原使用的 MDIncrementalRefreshTradeSummary42 id="42"
MDIncrementalRefreshDailyStatistics49 id="49" ==>取代原使用的 MDIncrementalRefreshDailyStatistics33 id="33"
MDIncrementalRefreshLimitsBanding50 id="50" ==>取代原使用的 MDIncrementalRefreshLimitsBanding34 id="34"
MDIncrementalRefreshSessionStatistics51 id="51" ==>取代原使用的 MDIncrementalRefreshSessionStatistics35 id="35"
SnapshotFullRefresh52 id="52" //未使用, 與 SnapshotFullRefresh38相同,只是PRICENULL改用PRICENULL9
SnapshotFullRefreshOrderBook53 id="53" //行情沒用到
MDInstrumentDefinitionFuture54 id="54" ==>取代原使用的 MDInstrumentDefinitionFuture27 id="27"
MDInstrumentDefinitionOption55 id="55" ==>取代原使用的 MDInstrumentDefinitionOption41 id="41"
MDInstrumentDefinitionSpread56 id="56" ==>取代原使用的 MDInstrumentDefinitionSpread29 id="29"
若依廠商提供的 CME更換行情格式，行事曆
行事曆本身說明了系統最好能新舊格式通吃,
以CME而言就是行事曆時間之前丟舊格式, 時間以後改丟新格式
若GMDS系統尚未更新, 只能解舊格式的會於行事曆時間以後沒有行情
雖然廠商很誇張, 5月就已經提供的新格式, 到8月有商品沒行情的第一天8/13號之後才發現,
雖然8/15號才收到消息, 但是看了一下之前的程式碼, 只能誇讚自己寫的太好了,
估計能連線到系統時, 應該半天就能完工~
改版訊息查閱: 2018-08-16
其他相關文章