飽和演算

飽和演算は、加算や乗算などのすべての演算が最小値と最大値の間の固定範囲に制限される 演算バージョンです。

演算結果が最大値より大きい場合は、最大値に設定 (「クランプ」) されます。最小値より小さい場合は、最小値にクランプされます。この名前は、値が極値に達すると「飽和」することから来ています。最大値にさらに加算したり、最小値から減算したりしても、結果は変わりません。

たとえば、有効な値の範囲が -100 から 100 の場合、次の飽和算術演算によって次の値が生成されます。

• 60 + 30 → 90。
• 60 + 43 → 100。（予想の103ではありません。）
• (60 + 43) − (75 + 25) → 0. (予想された3ではありません。) (100 − 100 → 0.)
• 10 × 11 → 100。（予想された110ではありません。）
• 99 × 99 → 100。（予想された9801ではありません。）
• 30 × (5 − 1) → 100. (予想された120ではありません。) (30 × 4 → 100.)
• (30 × 5) − (30 × 1) → 70。(予想された120ではありません。前の100ではありません。) (100 − 30 → 70。)

有効範囲が 0 から 100 の場合の 飽和減算の別の例を次に示します。

• 30 - 60 → 0. (予想された -30 ではありません。)

これらの例からわかるように、結合法則や分配法則などのよく知られた性質は、飽和演算では当てはまらない場合があります。^{[a]このため、}抽象数学では扱いにくいのですが、値が最大と最小の表現範囲を持つ デジタルハードウェアやアルゴリズムでは重要な役割を果たします。

通常、汎用マイクロプロセッサは、飽和演算を使用した整数演算を実装しません。代わりに、実装が簡単なモジュラー演算を使用します。モジュラー演算では、時計の時間が 12 から 1 に移行するのと同じように、最大​​値を超える値が最小値に「ラップアラウンド」します。ハードウェアでは、最小値が 0、最大値がr ⁿ − 1 ( rは基数) のモジュラー演算は、最下位のn桁以外をすべて破棄するだけで実装できます。現代のハードウェアの大部分がそうであるバイナリ ハードウェアでは、基数は 2 で、桁はビットです。

しかし、実装はより困難であるものの、飽和演算には多くの実用的な利点があります。結果は真の答えに可能な限り数値的に近くなります。8 ビットの 2 進符号付き演算では、正しい答えが 130 の場合、飽和演算から 127 という答えを得ることは、モジュラー演算から -126 という答えを得ることより、かなり意外ではありません。同様に、8 ビットの 2 進符号なし演算では、正しい答えが 258 の場合、飽和演算から 255 という答えを得ることは、モジュラー演算から 2 という答えを得ることより、意外ではありません。

飽和演算では、最大値または最小値との単純な比較によって、オーバーフロー ビットや過剰な計算なしで、加算と乗算のオーバーフローを一貫して検出することもできます (データがこれらの値を取ることを許可されていない場合)。

さらに、飽和演算は、特にデジタル信号処理において、多くの問題に対して効率的なアルゴリズムを可能にします。たとえば、音声信号の音量レベルを調整するとオーバーフローが発生する可能性がありますが、飽和はラップアラウンドよりもサウンドの歪みを大幅に少なくします。研究者のGAコンスタンティニデスらは次のように述べています。^[1]

2 の補数表現を使用して 2 つの数値を加算すると、オーバーフローによって「ラップアラウンド」現象が発生します。その結果、DSP システムで信号対雑音比が壊滅的に低下する可能性があります。したがって、DSP 設計の信号は通常、最も極端な入力ベクトルを除くすべての入力ベクトルでオーバーフローを回避するために適切にスケーリングされるか、飽和演算コンポーネントを使用して生成されます。

飽和演算は多くの最新プラットフォームで利用可能であり、特に Intel MMXプラットフォームによって、このような信号処理アプリケーション向けに作成された拡張機能の 1 つでした。この機能は、 SSE2およびAVX2整数命令セットのより幅広いバージョンでも利用できます。また、ARM NEON命令セット でも利用できます。

整数の飽和演算は、 GNUコンパイラコレクション、^[2] LLVM IR、Eiffelなど、 C、C++を含む多くのプログラミング言語のソフトウェアにも実装されています。飽和演算のサポートは、 C++26標準ライブラリの一部として含まれています。これにより、プログラマはオーバーフローの影響をより適切に予測して理解することができ、コンパイラの場合は通常、最適なソリューションを選択できます。

飽和は、モジュラー算術演算のみを備えたマシン上でソフトウェアで効率的に実装するのが難しい。単純な実装では、膨大なパイプライン遅延を生み出す分岐が必要になるからだ。しかし、モジュラー算術演算とビット単位の論理演算のみを使用して、分岐のないソフトウェアで飽和加算と減算を実装することは可能だ。これらの演算は、すべてのx86 CPU（オリジナルのIntel 8086まで遡る）と一部の一般的な8ビットCPU（ Zilog Z80など、現在も生産されているものもある）を含むすべての最新CPUとその前身で利用できる。一方、単純な8ビットおよび16ビットCPUでは、パイプラインが停止せず、各命令が常に複数のクロックサイクルを要するため、アセンブリ言語でプログラムすると分岐アルゴリズムの方が実際には高速になる可能性がある。オーバーフローフラグと条件付き移動を提供するx86では、非常に単純な分岐のないコードが可能である。^[3]

ハードウェアにおける整数演算では飽和演算はあまり一般的ではありませんが、近似実数を扱うための最も一般的な抽象化であるIEEE 浮動小数点標準 では、オーバーフローが「無限大」または「負の無限大」に変換され、この結果に対する他の演算で同じ値が引き続き生成されるという飽和形式が使用されています。これは、単純な飽和に比べて、値を減らす後の演算で、計算 のように誤解を招くような「妥当な」結果が生成されないという利点があります。あるいは、「指数オーバーフロー」(および「指数アンダーフロー」) などの特別な状態が存在する可能性があり、これは後続の演算でも同様に持続するか、即時終了を引き起こしたり、IBM 704用の FORTRAN (1956 年 10 月) のように でテストされたりします。 ${\textstyle {\sqrt {x^{2}-y^{2}}}}$IF ACCUMULATOR OVERFLOW ...

• 検閲（統計）

• SARITH: 安全な算術演算 - 進捗レポート: Eiffelの飽和演算コンポーネントに関するレポート。
• saturating は、GCC Overflow 組み込み関数に基づいて飽和演算を行うヘッダーのみの C++ ライブラリです。