- 3.3 加算と減算
- 3章に入って、文章が少しわかりにくくなった。原文がそうなのか、訳文がそうなのか。
- 「32ビットの数値を2つ加算または減算すると、結果を完全に表現するには33ビットを必要とする場合がある」うーん。わからん。
- 自分なりに考える。
- まず符号付き整数の場合。
- 正の整数で表現できる最大は、01...1。では01...1 + 01...1は、というと、1...10。ということで、これは32ビット符号付き整数の観点では、負の数になる。なので、これを正の数として正しく表現するにはこれの頭に符号ビットがあるべきであり、すると33ビット必要ということ。
- 続いて、負の整数で表現できる最小は、10...0。10...0 + 10...0は、というと(1)0...0。ということで、桁上がりしたものを格納するビットがない。よってこの演算において結果が正しく表現されるには、そもそも33ビットにて符号付き整数を定義しておく必要があったと考えられる。
- 理解できた。
- 「減算においては、正の数から負の数を引いた結果が負の場合、または負の数から正の数を引いた結果が正の場合に、オーバフローが発生したといえる」
- わからない。。。
- 自分なりに考える。
- 前者は正の数どうしの足し算なので、わかる。
- 後者は負の数どうしの足し算なんだけど、上の例で、(1)0...0となったときの最上位ビットが"0"というのが判定条件になる、ということがここまでの話の中身のみで自明だと言えるとは思えない。
- "32ビット符号付き整数の負数a,bがあるとき、a+bが33ビット目に桁上がりするならば、32ビット目は必ず0である"ということを確認or証明するということ。
- このとき負数は、最上位ビットが必ず1であり、残りのビットは0でも1でもよい、という形式である。
- よって、負数を加算したとき、必ず架空の33ビット目への桁上がりが発生する。
- すると、負数の形式から、正しく結果を表現できるときは、31ビット目までの0と1のあり様がどのようなものであっても32ビット目に桁上がりすることを証明せねばならない。これはちょっとわからない。。。
- なので、「修正2の補数」の考え方をつかって正の数で考えてみる。
- 10...0以外の負数は、「修正2の補数」の手順に従って同じ大きさの正の数に変換できる。
- aとbが10...0以外だとする。それらを正の数に変換したものをAとBとする。
- するとA+Bの結果が正しく表現できないのは、32ビット目に桁上がりして負数の表現になってしまう場合である。すなわち1?...?の形式となる場合。
- さて、その負数となってしまった表現をCとする。
- また架空の33ビット目を考えて33ビットによる表現に拡張して議論する。
- すると、その拡張解釈ではCは負数ではないし、正しい結果の表現である。
- そのCに対応する負数を「修正2の補数」で考える。
- するとそれは、(1)0?...? + 1となる。
- ここで、+1によって、32ビット目に桁上がりするのは、(1)01...1の場合だけである。され、これはCが10...0の場合である。これ以外は32ビット目への桁上がりがないので、32ビット目が0、すなわち、32ビット符号付き整数の形式にて正になっている。
- Cが10...0の場合は、一応例としてあげると
0111 1111 1111 1111 1111 1111 1111 1111
＋0000 0000 0000 0000 0000 0000 0000 0001
0111 1111 1111 1111 1111 1111 1111 1101
＋0000 0000 0000 0000 0000 0000 0000 0011
などの場合である。 - さて、この場合は、32ビット符号付き整数の正の整数の加算としてはオーバフローしているが、32ビット符号付き整数にて負数は正数よりもひとつ多く、10...0も正しい負数として表現できるので、この桁上がりのケースは正しく結果を表現できているとしてよい■
- 以上にて、
「負数どうしの減算がオーバフローするときは必ず最上位ビットが0になる、といえる」
- このとき負数は、最上位ビットが必ず1であり、残りのビットは0でも1でもよい、という形式である。
- なんかすっきりしないなぁ。
- 3章に入って、文章が少しわかりにくくなった。原文がそうなのか、訳文がそうなのか。
一応これでよしとする。
次は乗算。
0 件のコメント:
コメントを投稿