バックナンバーはこちら。
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のようなテーブル情報と変換先の文字列を格納している。
バックナンバーはこちら。
コメント