バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
作成してMDFをMDF validatorで確認した。
DataGroup、ChannelGroupは想定通りの構成で、
物理変換式も一緒に確認していく。
今回も引き続き残りの物理変換式を確認。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
tabular without interpolation
次はt10ms_tabular。
確かテーブル変換で、補間無しのパターンだったね。
これもMDF validatorで見てみよう。
これも想定通りかな。
変換のパラメータはcc_valに並んで埋まっているのか。
変換元、変換先の順番が3セットある感じだね。
ふと思ったんだけど、
パラメータが埋まってるcc_valって前回のlinear conversionだと2個だけだったけど、
今回は6個もあるね？
どこで個数が決まるんだろう？
cc_val_countってパラメータがあってそこにcc_valの個数が指定されてるはずだよ。
あ、ホントだ。
今回のだと6ってなってるから、これで6個のcc_valを持つことが分かるわけか。
tabular with interpolation
次はt10ms_tabular_inpだけど、
構造的には多分t10ms_tabularと一緒だよね。
そうだね。
変換方式が違うだけでパラメータは一緒だったはず。
MDF validatorで確認してみよう。
太郎くん：
予想通り、cc_typeが違うだけで後はt10ms_tabularと一緒だ。
value to text
次はt10ms_value_to_textだけど、
これは結構ややこしいことになってそうだなー。
変換テーブルで受けて文字列に変換だから。
そうだね。
tabular的な仕様に加えて文字列の情報が必要になるもんね。
まぁこれも見てしまおう。
やっぱりややこしいことになってる・・・。
でもまぁ想定通りってことでもあるかな。
tabularと同じくcc_valにテーブル情報が入って、cc_refで変換文字列を参照してる感じだ。
ふむ。
必要な情報がちゃんと漏れなく入ってると思って良いだろう。
まとめ
まとめだよ。
- 今回もMDF Validatorで物理変換式を確認。
- tabular without interpolationとtabular with interpolationはcc_typeが違うだけで保持している情報は一緒。
- value to textはtabularのようなテーブル情報と変換先の文字列を格納している。
バックナンバーはこちら。
コメント