4月に職場に来た人の歓迎会をやってほしいという話があって、
いろいろ考えるもなかなか思うようにいかないものである。
でもとりあえず手配はできたからいいか。
浮動小数点数は難しいなと思うことがあった。
マイコンで測定した値を一定の演算を行うと、例えば-100～100の値に変換される。
この値が指定された値を出たらフラグを立てるという処理がある。
ここで-100, 100ピッタリを指定した場合、フラグは立ってはいけないと思った。
ところがこの処理、浮動小数点演算で行わざるを得ず、変換後の値が-100～100をわずかにはみ出すことが判明。
この結果、-100, 100ピッタリを指定した場合もフラグが立つことがあると。
整数演算でやればこういう問題は避けられた可能性はあるが……
指定された値が –100, 100 ピッタリの場合に動作する処理を加えようかとか、
比較する前に整数化してしまうか、とかいろいろ考えたのだが、
浮動小数点演算の量が増えるのはあまり好ましいことではないか……
なんてことを考えた結果、変換時のパラメータを微調整することで解決した。
例えばパラメータに 1666.666 となっていたのを 1666.668 にするとか。
最終的な演算結果では浮動小数点の仮数部の1digitの差とか、そんなところを突き詰める微調整だった。
結果として従来のアルゴリズムはほぼ変えずに問題を解決できた。
こういう解決方法ってどうですかね? とチームリーダーに相談にいくと、
微調整により他の部分の演算結果が若干変わるけど影響ないかと。
測定結果のばらつきの方が大きいだろうと断言できる話である。
しかし、これだけ細かい微調整だと、移植などで影響も受けそうだが。
特に移植を想定しているわけではないが気になるところである。
過去に浮動小数点演算であれこれやったことが一度あったが、
そのときは測定値の端がとんでもない数字に吹っ飛ぶ仕組みだった。
なのでこういう問題は考えることもなかった。
そもそも –100, 100のような端の値を指定したときにフラグが立たないなんて約束はどこにもなかったのだが、
社内ではこういう考えが一般的なので、これも大丈夫だっけ? とテストすると案の定ダメという。