「緊急地震速報の「誤報」はプログラム中の「単位」間違えが原因と判明」記事へのコメント

今朝聞いた話だと

[Tatenon (20311)]

通勤中にラジオで聞いた話だと、
小数点以下を切り捨て→四捨五入に仕様変更しようとして、
0.5umを0.5mmにしてしまい、
2.5umが525umになってしまったと。

謎なのはこの間違いをやらかすロジック。

四捨五入がなぜ単位違いになるのか。
単位だけ変えてなぜそのまま加算するのか。
なぜ１０倍でなくて１０００倍なのか。

どういう間違いをすればこうなるのか、さっぱり予想できない。
う～ん。みすてりぃ。

# 誰かさんは昔うるう年計算の処理間違えたけどな。
## 15年も前の話だ。

自己レス

[Tatenon (20311)]

朝日の記事を読み返していて気づいた。

『常に５００マイクロメートル大きくなる』

要するに0.5を足した後小数点以下切り捨てで四捨五入しようとしたと。
そしたら0.5じゃなくて500を足すようになっていたと。

ラジオだと25.5の0.5が500になって25+0.5ではなく25+500で525になったと言ってたので、
このロジックとは異なる。

# でも1000倍の謎は残るなぁ。浮動小数点じゃなくてBCD計算なんだろうか。

Re:

[SS1 (6823)]

# でも1000倍の謎は残るなぁ。浮動小数点じゃなくてBCD計算なんだろうか。

つーか。単位がよくわからないね。マイクロメートル／秒なのか，マイクロメートル／毎秒毎秒なのか，特定時刻：マイクロメートル変異量なのか。各社の科学部は何をしているんだか・・・

「浮動小数点じゃなくてBCD計算なんだろうか。」

組み込み用プロセッサって，たいていがコプロ無しなのと，入力データが大抵はAD値（多くて１６ビットくらいの）なので，普通は（固定小数点の）整数演算ですが，(震度やマグニチュードのように)Log演算を伴う場合は，言語の演算ライブラリを使って浮動小数点数を使うのが一般的です。

ただ地震計のように，重

--
斜点是不是先進的先端的鉄道部長的…有信心

Re:自己レス

[Tatenon (20311)]

浮動小数点でなく整数演算ってのは私も考えたんですよね。
小数点以下切捨てって言ってたので、単純に浮動小数点→整数で
やってんじゃないのかと。

でSS1氏のコメントで思いついたのですが、
『実は最初から整数のみのデータ』だったかもしれない。

つまり25.5nmは浮動小数点数25.5でなく10倍した整数255で保持してたかも。
計測器からのデータだとよくある話ですよね。
つまり従来の小数点以下切捨ては
nm=255
nm/10 → 25
で行っていたと考えられます。

で、『nmの四捨五入』を『mmの四捨五入』と勘違いしたマヌケが（ここが一番謎だが）
nm=255
(nm+5000)/10 → 525
　　　　　　　　↑ﾏﾃ
とやらかした。でもこれ実際にｍｍで四捨五入するつもりなら
nm=255
(nm+5000)/10000 → 0

になってるべきであり、正しく実装されたらモノホンの大地震でも速報が出なかった可能性があると。(gkbr)

全ては予想の範囲を出てませんが、何にしてもテストも検証も一度もやらなかったのが
最悪のミスであることは確実なので、どうこう言っても始まりませんけどね・・・