This is caused by the Wii VC incorrectly converting the MIPS cvt.s.d instruction to the PowerPC stfs instruction. With the latter, double to single precision floating point conversion is undefined. The Wii uses round-to-zero for this conversion, while SM64 uses round-to-nearest. 【適当な訳】 このバグは、WiiVCが内部的にMIPS(64のCPU)の命令「cvt.s.d」をPowerPC(WiiのCPU)の命令「stfs」に変換することによって発生します。stfsは倍精度から単精度
設計がおかしいのか? (スコア:1)
浮動小数点演算の規格IEEE754では複数の丸めモードが定義されているが、同じ丸めモードだったら処理結果は完全に一致するのではないのか?
それともIEEE754とは無関係に独自実装したのか?
Re: (スコア:5, 参考になる)
リンク先でたどれるGoogleドキュメントの [google.com]「Wii VC Rounding / BitFS Platform Drift」という項目によると、
Re: (スコア:0)
PowerPCのstfsを使わずに最近接丸めをソフト処理すりゃ直る程度の話かな。
Re: (スコア:0)
それよりは、計算誤差でどんどんズレるソフトの設計がマズいんじゃないかと。
Re: (スコア:0)
設計は最近接丸めを想定していたのにエミュレーションの実装が不完全なのが悪い(まあ普通問題になることではないが)
Re:設計がおかしいのか? (スコア:0)
この丸めだから、どんなに計算を繰り返しても誤差は想定内に収まる、と証明するのは相当難しそうだと思うけど。
問題になってる程度のプログラムなら、1周期分計算したら丁度同じ値になった、他の値は取りえない、これで大丈夫、ぐらいで証明できる可能性もあるけど。
もし、そういう分かりやすい性質がなかったら、かなり大変。
ちゃんと証明できるとしたら、ガチの数値計算の専門家ぐらい。
(まともな大学の工学系だと、カリキュラムのどこかで、計算誤差の注意点については習うはず。
浮動小数点数の計算順序を変えただけで誤差が大きく変わってくるとかそういう。
プログラマなら誰でも知ってるはずの「2つの浮動小数点数が(ほぼ)等しい」かどうかを判定するアルゴリズムなんかはその基礎の基礎。
講義で扱われる内容はその初歩で、ドヤ顔で講義されてる先生は、普段、もっとややこしい問題に取り組んでらっしゃる)
でも、逆に「誤差が想定を超えうる」ことが証明されちゃう可能性の方が高いと思う。
あるいは、どうせそうなるんだから、無駄なことに時間を使うな、と怒られるか。
一方で、計算の正確さが要求されないゲーム用に、時間経過とともに誤差が蓄積しないようなプログラムを書け、
なら、プログラマを名乗ってれば誰でも簡単にできる。不要な積算はこの手のトラブルの元だからそもそも避けるべきだし、
避けがたいなら「だいたい1周期が過ぎたら初期位置の座標値を代入して強制的に初期位置に戻す」みたいな処理でも入れとけば良い。
(ある建物の設計が地震で壊れないかを調査する、とかその手の物理シミュレーションが目的だったら、
そんな変な処理を入れると、シミュレーション結果が台無しになるからやっちゃ駄目だけど、ゲームなら十分にそれっぽく見えればそれで十分)
で、ちゃんと証明するよりも、証明できる事を期待して慎重に1周期分の数値計算結果を検討したりするよりも、楽で安全。