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

今朝聞いた話だと

[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演算を伴う場合は，言語の演算ライブラリを使って浮動小数点数を使うのが一般的です。

ただ地震計のように，重力加速度(9.8m／s²)超から，潮汐1cm／h（？？）近くまで測定するやつとなると，それなりにノウハウが必要になってくるはず。私にはセンサの方式が思いつかない。

でもって組み込みシステムは，前述のようにCPUが貧弱な場合が多いので計算量が増えるとADサンプリングとか通信する暇がなくなるのね。おまけに緊急速報用ってことは，応答時間（最後のサンプリングから，緊急信号出力までの時間）が１秒以下とか，そういう要求仕様になってるわけでしょ。

もとから無理のある要求仕様（＆方式設計）だったんじゃないかな。

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

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)

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

Re:自己レス なるほど

[Anonymous Coward]

ニュース読んでてなんじゃこれ？って思ってたけど

やっとわかった。

社内では　ｄBμ　と　ｄBｍの違いで

（よくあるように？）ｄＢ　としか表記してなかったのでは

と言ってた人がいましたけど

Re:

[Anonymous Coward]

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

全然外しているかもしれないけど、揺れ幅の単位がマイクロメートルだったのを
ミリメートルとして取り扱ったと聞きました。
1ミリメートルは1000マイクロメートルですよね？

文科省の押し進めた「ゆとり」な技術者が社会に出ると、このような
愉快な事件が起こるわけですね。