トップページ > プログラム > 2017年03月24日 > RtKD05ZR0

書き込み順位&時間帯一覧

13 位/238 ID中時間01234567891011121314151617181920212223Total
書き込み数1210000000000000000000004



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん (ワッチョイ 1bc8-VHv+)
C++相談室 part129 [無断転載禁止]©2ch.net

書き込みレス一覧

C++相談室 part129 [無断転載禁止]©2ch.net
891 :デフォルトの名無しさん (ワッチョイ 1bc8-VHv+)[sage]:2017/03/24(金) 00:17:14.57 ID:RtKD05ZR0
>>889
マジカヨ?ちょっとその仕事試しに受けてみたいかも。
それってどれくらいの規模だった?
C++相談室 part129 [無断転載禁止]©2ch.net
895 :デフォルトの名無しさん (ワッチョイ 1bc8-VHv+)[sage]:2017/03/24(金) 01:25:52.24 ID:RtKD05ZR0
>>887
ついでにこんなんが出てきたので貼っておく。
> サイン、コサインをインテルの CPU で計算すると少しバグっているらしい
> http://tomeapp.jp/archives/1282

要するに、x87のアセンブラ命令 FSIN, FCOS 等には誤差が出る場合があって、
これを嫌うコンパイラの場合は自前で計算しているらしい。
だからコンパイラを変更した場合、sin,cosの値が微妙にずれる事があり得る。
VC6->VC9でどうなのかは知らん。
C++相談室 part129 [無断転載禁止]©2ch.net
897 :デフォルトの名無しさん (ワッチョイ 1bc8-VHv+)[sage]:2017/03/24(金) 01:58:41.18 ID:RtKD05ZR0
俺はこれは初耳だったからよくは知らない。

> In a single Intel publication, the problem is partially acknowledged. The 1999 edition of Intel Architecture Software Developer’s Manual Volume 1: Basic Architecture (download) states:
>
> The trigonometric instructions may use a 66-bit approximation to the true value of pi to reduce the magnitude of the input argument. In this case, the final computed result can vary considerably from the true mathematically precise result.
>
> This statement, which never again appears in a public Intel document, acknowledges the argument reduction problem. However, the entirely separate problem of large errors near argument multiples of pi/2 is not addressed.
> http://notabs.org/fpuaccuracy/index.htm
主張としては、sinXのXが無駄にでかい時は仕方ないとして、
pi/2の倍数のところに誤差があるのは駄目だろ、ということらしい。
つっても仮数部が10bit多いし、doubleに丸めるなら見えなくなると思うが。

正直なところ、浮動小数点の演算結果比較はこの手の落とし穴が大量にあるから、
完全一致は諦めて、4bit位の誤差までは見逃すようにしないと現実的に無理だと思う。
C++相談室 part129 [無断転載禁止]©2ch.net
899 :デフォルトの名無しさん (ワッチョイ 1bc8-VHv+)[sage]:2017/03/24(金) 02:49:48.36 ID:RtKD05ZR0
>>898
いやその話じゃない。FSIN,FCOSの誤差の話は、
Intelは 1.0ulp 誤差だと言っているのにそうなってない、という話。
(とは言え仮数部が10bit多いのだが)

君が言っているのは数学的なものとだろ?
それは浮動小数点では誤差があるのが仕様。

> floorで切り捨てているから、52+1=53 になるはずなのに、54になる!
これは間違い。以下。
Math.floor(Math.log2(Math.pow(2,53)-1))+1 // 54で正しい。
Math.log2(Math.pow(2,53)-1) は、52よりも53に限りなく近いから、53になる。

> これは、除数・被除数ともに誤差があるから、時々おかしくなる
これも上記の通り、認識間違い。
Math.LN2はそもそも「浮動小数点的には」誤差がない。
というより計算済みの値が使われる(はず)
Math.log2(x)等の関数は一般的に割り算での実装はされないはず。
理由は以下。
・割り算は誤差が出やすい(多分テーラー展開式等が使われる)
・割り算は遅い
・そもそも固定値割り算は逆数の掛け算に変更される
(とはいえ、現実的にはこの方法は割り算よりも誤差が出たりするが)
だから、
> Math.log2(x) = Math.log(x) / Math.LN2
が成立しない時も、それは浮動小数点計算による誤差であり、仕様。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。