5

私は、C11またはC99のいずれかがこの点で提供することを保証するものがあるかどうか疑問に思っています。

経験的に、浮動小数点値を（精度に関係なく）符号付き整数に変換すると、その符号付き整数範囲で浮動小数点値を表現できない場合でも、イベントが発生した場合でも、「適切な」飽和状態になるようです。浮動小数点値がプラスまたはマイナスの無限大であること（ただし、NaNの場合はわかりません）。

ここには微妙な問題があります。それは、丸め動作の違いが飽和を引き起こす場合もあれば、そうでない場合もあります。特に、飽和境界の端にいる場合はそうです。私はそれについて心配していません。私の質問は、浮動小数点機構が出力する必要のある整数（プラットフォームに依存する）を決定した後、その整数がターゲットの符号付き整数の範囲外にある場合（プラットフォームに依存しない）かどうかです。 ）、仕様によって飽和が保証されているかどうか。

私のデフォルトの理解は、私が見ているのは単に基盤となるハードウェアの便宜であり、署名されたオーバーフローが定義されていないため、そのような動作は保証されないということです。私は署名されたオーバーフローを嫌い、それを避けようとしているので、私が間違っていることを願っています。そうです、符号なし整数への変換の場合にも興味があります。

私がそれにいる間、負の0はどうですか？この値は、ある意味では負のイプシロンと考えることができますが、通常は-1に丸められますが、整数ゼロに変換されることが保証されていますか？

4

3 に答える 3

10

6.3.1.4実数浮動小数点と整数

実際の浮動小数点型の有限値が_Bool以外の整数型に変換されると、小数部は破棄されます（つまり、値はゼロに向かって切り捨てられます）。整数部の値を整数型で表現できない場合の動作は未定義です。）

于 2013-01-22T13:37:23.413 に答える
3

phresnelは、あなたの質問の主な目的に答える素晴らしい仕事をすでに行っています。覚えておくべき他のいくつかの詳細：

そうです、符号なし整数への変換の場合にも興味があります。

署名されていない状況は、これ以上良いものではありません。C11の脚注61（同じ脚注がC99にあります）：

整数型の値が符号なし型に変換されるときに実行される残りの操作は、実際の浮動型の値が符号なし型に変換されるときに実行する必要はありません。したがって、ポータブル実浮動値の範囲は（-1、Utype_MAX + 1）です。

幸い、これは符号付きと符号なしの両方の変換で簡単に修正できます。飽和が必要な場合は、変換する前に入力をクランプするだけです。

私がそれにいる間、負の0はどうですか？この値は、ある意味では負のイプシロンと考えることができますが、通常は-1に丸められますが、整数ゼロに変換されることが保証されていますか？

はい、整数ゼロに変換することが保証されています。まず、の値-0は正確にゼロであり、負のイプシロンではありません（インターネットで読んだ噂とは異なります）。次に、浮動小数点から整数への変換によって値が切り捨てられます。したがって、値が「負のイプシロン」（意味が何であれ）であっても、「負のイプシロン」は区間（-1、1）にあるため、結果はゼロになります。

于 2013-01-23T00:53:41.853 に答える
1

私がそれにいる間、負の0はどうですか？この値は、ある意味では負のイプシロンと考えることができますが、通常は-1に丸められますが、整数ゼロに変換されることが保証されていますか？

切り捨てられるため、ゼロに向かって進みます。つまり、1.0未満で-1.0より大きいものはすべて0になります。「一般的な」プラットフォームに関する限り、負のゼロはゼロになります。これが標準によって保証されているかどうかは完全にはわかりませんが、実際には、標準で定義されていなくても、信頼できると思います[コードを非常に「奇妙な」機器で実行する予定がない限り、 DSPやGPUなど]。

于 2013-01-22T13:47:57.950 に答える