アカウント名:
パスワード:
記事によると、> 振幅が実際よりも常に500マイクロメートル大きくなるようになったとのことなので、単位を間違えたというより、四捨五入の桁処理を間違えたって感じじゃないですかね。
想像ですが、mm単位な変数でμm単位の四捨五入するのに、data = int((data*1000.0)+0.5)*0.001;みたいなコードを書くつもりが、data = int((data+0.5)*1000.0)*0.001;ってやっちゃった、とか。
1998年に打ち上げられた米国の火星探査機マーズ・クライメイト・オービターは1999年に火星周回軌道投入の為の軌道修正後に消息不明に・・・。
調査委員会の報告によるとこの失敗の原因は、探査機のあるデータがメートル法で報告されるはずが、ヤード・ポンド法によって報告されていたという、航行上のミスによるものと判明した。これにより、探査機は、軌道進入の際に、予定されていた火星の140-150 km上空の軌道ではなく、57 km上空の軌道に進入した。このような低軌道では探査機は、大気の圧力と摩擦に耐え切れずに破壊されてしまった。
日本に限らずこんな事ってあるんですな。
ちょいと事実誤認があるようですな。
つまり、探査機のハードウェアを製造した側はヤード・ポンド系でデータを送信するように設計してたけど、探査機の管制を行う側はその値をメートルと解釈していた、というのが実情。
要は、お互いに相手が自分と同じ単位系を使っているものと勘違いしていた、という話で、一方的に「メートルで報告すべきところをヤードで報告していた」という話ではありません。
参考:JST失敗知識データベース > 失敗事例 > コミュニケーション不足による火星探査機の炎上 [jst.go.jp]
# でも1000倍の謎は残るなぁ。浮動小数点じゃなくてBCD計算なんだろうか。
つーか。単位がよくわからないね。マイクロメートル/秒なのか,マイクロメートル/毎秒毎秒なのか,特定時刻:マイクロメートル変異量なのか。各社の科学部は何をしているんだか・・・
「浮動小数点じゃなくてBCD計算なんだろうか。」
組み込み用プロセッサって,たいていがコプロ無しなのと,入力データが大抵はAD値(多くて16ビットくらいの)なので,普通は(固定小数点の)整数演算ですが,(震度やマグニチュードのように)Log演算を伴う場合は,言語の演算ライブラリを使って浮動小数点数を使うのが一般的です。
ただ地震計のように,重力加速度(9.8m/s2)超から,潮汐1cm/h(??)近くまで測定するやつとなると,それなりにノウハウが必要になってくるはず。私にはセンサの方式が思いつかない。
でもって組み込みシステムは,前述のようにCPUが貧弱な場合が多いので計算量が増えるとADサンプリングとか通信する暇がなくなるのね。おまけに緊急速報用ってことは,応答時間(最後のサンプリングから,緊急信号出力までの時間)が1秒以下とか,そういう要求仕様になってるわけでしょ。
もとから無理のある要求仕様(&方式設計)だったんじゃないかな。
ニュース読んでてなんじゃこれ?って思ってたけど
やっとわかった。
社内では dBμ と dBmの違いで
(よくあるように?)dB としか表記してなかったのでは
と言ってた人がいましたけど
当時の気象庁のホームページの「魚拓」 [megalodon.jp]によると、震度5弱の速報をだしたのとは別に、マグニチュードが214748364.7と算出された記録もあるんです。
プログラム的には、あぁなるほどー と思わなくも無い数字ですけど、どうしてこんな数字になるんでしょうね…… 単位間違いとは別の問題なんでしょうか。
マイクロ、マイクロ、綴りは……microか!よし、mm と。
……だったりして。
# 担当者が船ヲタとか軍ヲタとかだったら有るかもしれんが:-P
ここが今日のエスパースレですね。
ドキュメント「m単位で四捨五入すること」実装者「ばーかメートルなわけねーだろどんだけ大雑把だよwwwミリメートルだろwww」実際はもっと小さかったというオチ
# まさかね・・・
じつは本当に変数の内容はメートル単位で、0.0000005と入力しなければならないところを0.0005と入力したとか。変数の値は(物理量の場合)すべてSI単位に統一すべきだ!なんて方針だったとか。
これだけゼロを入力しなければならなかったとすれば、混乱して間違うこともあるかもしれない。(こういう場合は0.5e-6とか5e-7と入力するべきなんでしょうけど)。
変数の値は(物理量の場合)すべてSI単位に統一すべきだ!なんて方針だったとか。
ミリメートルもマイクロメートルもSI単位ですよ(より詳しく言えば「SI基本単位にSI接頭語がついたもの」ですけど、それも「SI単位」ですから)。
だから、仰りたいような方針は「変数の値は(物理量の場合)すべてSI基本単位に統一すべきだ!接頭語の使用も認めない!」と書かれるべきでしょう。もっとも、これでは組立単位も使えなくなってしまうので、それはそれで面倒かもしれません(力の単位を一々m kg s^(-2)と書かなきゃいけないとか)。
> どういう間違いをすればこうなるのか、さっぱり予想できない。
ドキュメント内で、Symbolフォントでマイクロを表現していて、どこかでフォント情報が脱落したとか。メモ帳等のテキストエディタを介在させてコピペすれば、フォント情報が脱落しますし。
往年のFortranバグでロケットがアレになった奴じゃないが、最近は単位を扱えるプログラム言語とか、単位を言語内DSLで書く(ようにしても無理があまり出ない)言語も有るんで、そういう「より高級な」言語にいったらいいんとちゃうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
今朝聞いた話だと (スコア:2, 興味深い)
小数点以下を切り捨て→四捨五入に仕様変更しようとして、
0.5umを0.5mmにしてしまい、
2.5umが525umになってしまったと。
謎なのはこの間違いをやらかすロジック。
四捨五入がなぜ単位違いになるのか。
単位だけ変えてなぜそのまま加算するのか。
なぜ10倍でなくて1000倍なのか。
どういう間違いをすればこうなるのか、さっぱり予想できない。
う~ん。みすてりぃ。
# 誰かさんは昔うるう年計算の処理間違えたけどな。
## 15年も前の話だ。
Re:今朝聞いた話だと (スコア:3, 興味深い)
記事によると、
> 振幅が実際よりも常に500マイクロメートル大きくなるようになった
とのことなので、単位を間違えたというより、四捨五入の桁処理を間違えたって感じじゃないですかね。
想像ですが、mm単位な変数でμm単位の四捨五入するのに、
data = int((data*1000.0)+0.5)*0.001;
みたいなコードを書くつもりが、
data = int((data+0.5)*1000.0)*0.001;
ってやっちゃった、とか。
単位のミスはNASAでも (スコア:1, 興味深い)
1998年に打ち上げられた米国の火星探査機マーズ・クライメイト・オービターは
1999年に火星周回軌道投入の為の軌道修正後に消息不明に・・・。
調査委員会の報告によるとこの失敗の原因は、探査機のあるデータがメートル法で
報告されるはずが、ヤード・ポンド法によって報告されていたという、
航行上のミスによるものと判明した。これにより、探査機は、軌道進入の際に、
予定されていた火星の140-150 km上空の軌道ではなく、57 km上空の軌道に進入した。
このような低軌道では探査機は、大気の圧力と摩擦に耐え切れずに破壊されてしまった。
日本に限らずこんな事ってあるんですな。
Re: (スコア:0)
ちょいと事実誤認があるようですな。
つまり、探査機のハードウェアを製造した側はヤード・ポンド系でデータを送信するように設計してたけど、探査機の管制を行う側はその値をメートルと解釈していた、というのが実情。
要は、お互いに相手が自分と同じ単位系を使っているものと勘違いしていた、という話で、一方的に「メートルで報告すべきところをヤードで報告していた」という話ではありません。
参考:JST失敗知識データベース > 失敗事例 > コミュニケーション不足による火星探査機の炎上 [jst.go.jp]
自己レス (スコア:2, 興味深い)
『常に500マイクロメートル大きくなる』
要するに0.5を足した後小数点以下切り捨てで四捨五入しようとしたと。
そしたら0.5じゃなくて500を足すようになっていたと。
ラジオだと25.5の0.5が500になって25+0.5ではなく25+500で525になったと言ってたので、
このロジックとは異なる。
# でも1000倍の謎は残るなぁ。浮動小数点じゃなくてBCD計算なんだろうか。
Re:自己レス (スコア:2)
# でも1000倍の謎は残るなぁ。浮動小数点じゃなくてBCD計算なんだろうか。
つーか。単位がよくわからないね。マイクロメートル/秒なのか,マイクロメートル/毎秒毎秒なのか,特定時刻:マイクロメートル変異量なのか。各社の科学部は何をしているんだか・・・
「浮動小数点じゃなくてBCD計算なんだろうか。」
組み込み用プロセッサって,たいていがコプロ無しなのと,入力データが大抵はAD値(多くて16ビットくらいの)なので,普通は(固定小数点の)整数演算ですが,(震度やマグニチュードのように)Log演算を伴う場合は,言語の演算ライブラリを使って浮動小数点数を使うのが一般的です。
ただ地震計のように,重力加速度(9.8m/s2)超から,潮汐1cm/h(??)近くまで測定するやつとなると,それなりにノウハウが必要になってくるはず。私にはセンサの方式が思いつかない。
でもって組み込みシステムは,前述のようにCPUが貧弱な場合が多いので計算量が増えるとADサンプリングとか通信する暇がなくなるのね。おまけに緊急速報用ってことは,応答時間(最後のサンプリングから,緊急信号出力までの時間)が1秒以下とか,そういう要求仕様になってるわけでしょ。
もとから無理のある要求仕様(&方式設計)だったんじゃないかな。
斜点是不是先進的先端的鉄道部長的…有信心
Re:自己レス (スコア:1)
小数点以下切捨てって言ってたので、単純に浮動小数点→整数で
やってんじゃないのかと。
でSS1氏のコメントで思いついたのですが、
『実は最初から整数のみのデータ』だったかもしれない。
つまり25.5nmは浮動小数点数25.5でなく10倍した整数255で保持してたかも。
計測器からのデータだとよくある話ですよね。
つまり従来の小数点以下切捨ては
nm=255
nm/10 → 25
で行っていたと考えられます。
で、『nmの四捨五入』を『mmの四捨五入』と勘違いしたマヌケが(ここが一番謎だが)
nm=255
(nm+5000)/10 → 525
↑マテ
とやらかした。でもこれ実際にmmで四捨五入するつもりなら
nm=255
(nm+5000)/10000 → 0
になってるべきであり、正しく実装されたらモノホンの大地震でも速報が出なかった可能性があると。(gkbr)
全ては予想の範囲を出てませんが、何にしてもテストも検証も一度もやらなかったのが
最悪のミスであることは確実なので、どうこう言っても始まりませんけどね・・・
Re:自己レス なるほど (スコア:0)
ニュース読んでてなんじゃこれ?って思ってたけど
やっとわかった。
社内では dBμ と dBmの違いで
(よくあるように?)dB としか表記してなかったのでは
と言ってた人がいましたけど
Re: (スコア:0)
全然外しているかもしれないけど、揺れ幅の単位がマイクロメートルだったのを
ミリメートルとして取り扱ったと聞きました。
1ミリメートルは1000マイクロメートルですよね?
文科省の押し進めた「ゆとり」な技術者が社会に出ると、このような
愉快な事件が起こるわけですね。
Re:今朝聞いた話だと (スコア:2)
当時の気象庁のホームページの「魚拓」 [megalodon.jp]によると、震度5弱の速報をだしたのとは別に、マグニチュードが214748364.7と算出された記録もあるんです。
プログラム的には、あぁなるほどー と思わなくも無い数字ですけど、どうしてこんな数字になるんでしょうね…… 単位間違いとは別の問題なんでしょうか。
人生は七転び八起き、一日は早寝早起き
Re:今朝聞いた話だと (スコア:1)
マイクロ、マイクロ、綴りは……microか!
よし、mm と。
……だったりして。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:今朝聞いた話だと (スコア:1)
大きい方に間違えて発見が早まったのは不幸中の幸いだったのかもしれないですね・・・
Re: (スコア:0)
# 担当者が船ヲタとか軍ヲタとかだったら有るかもしれんが:-P
Re:今朝聞いた話だと (スコア:1, おもしろおかしい)
ここが今日のエスパースレですね。
ドキュメント「m単位で四捨五入すること」
実装者「ばーかメートルなわけねーだろどんだけ大雑把だよwwwミリメートルだろwww」
実際はもっと小さかったというオチ
# まさかね・・・
Re: (スコア:0)
Re: (スコア:0)
じつは本当に変数の内容はメートル単位で、0.0000005と入力しなければならないところを0.0005と入力したとか。
変数の値は(物理量の場合)すべてSI単位に統一すべきだ!なんて方針だったとか。
これだけゼロを入力しなければならなかったとすれば、混乱して間違うこともあるかもしれない。
(こういう場合は0.5e-6とか5e-7と入力するべきなんでしょうけど)。
Re: (スコア:0)
ミリメートルもマイクロメートルもSI単位ですよ(より詳しく言えば「SI基本単位にSI接頭語がついたもの」ですけど、それも「SI単位」ですから)。
だから、仰りたいような方針は「変数の値は(物理量の場合)すべてSI基本単位に統一すべきだ!接頭語の使用も認めない!」と書かれるべきでしょう。もっとも、これでは組立単位も使えなくなってしまうので、それはそれで面倒かもしれません(力の単位を一々m kg s^(-2)と書かなきゃいけないとか)。
Re: (スコア:0)
> どういう間違いをすればこうなるのか、さっぱり予想できない。
ドキュメント内で、Symbolフォントでマイクロを表現していて、どこかでフォント情報が脱落したとか。
メモ帳等のテキストエディタを介在させてコピペすれば、フォント情報が脱落しますし。
Re: (スコア:0)
時間の単位なんかを0.001倍にして、長さの単位を間違えたとかそんな感じじゃないですかね
Re: (スコア:0)
計測処理の観点からすると、そもそも四捨五入なんてする必要のないデータだと思うが、
その辺の仕様書なりドキュメントは確認したんだろうか?
Re: (スコア:0)
往年のFortranバグでロケットがアレになった奴じゃないが、
最近は単位を扱えるプログラム言語とか、
単位を言語内DSLで書く(ようにしても無理があまり出ない)言語も有るんで、
そういう「より高級な」言語にいったら
いいんとちゃうか?