次の問題は私を大いに混乱させました:
doubles
私はどのように、特にそれらの「特別な」値PositiveInfinity
がファイルに保存されるかを実験していましたが、問題はありませんでした。これは 3 つの簡単な手順で行いましたdouble
。ファイルに書き込みます。ファイルを配列に読み込みますbyte
。これは非常に簡単Double.NaN
で、バイナリ形式で a がどのように見えるかがわかりました:)
しかし、私は次のことに出くわしました:
.Net-Framework によると、次のものがありますNegativeZero
。
internal static double NegativeZero = BitConverter.Int64BitsToDouble(unchecked((long)0x8000000000000000));
表現方法は非常に単純です (IEEE 754 に従っています)。
はlong
2 進数を表します: 10000000...
最初のビットは、double
が負であることを示しています。したがって、仮数部と指数部が両方とも であるため、NegativeZero
を表すために起こることは.- 0 * 2^0
0
「通常の」0 を表すと、64 ビットがすべて に設定され0
ます。
しかし問題は、これらの数値をbyte
配列に読み込むことです。私が想定したのは、次のとおりですNegativeZero
: 128
0
0
... [バイナリ: 100000 ...]
しかし、実際にはそれは間違った方法でした: 0
0
... 128
! [バイナリ: 00000...0 10000000]
私が最初に考えたのは、「File.ReadAllBytes()
すべてが間違った順序で返される可能性がある (これは厄介なことです)」ということでした。そこで、リーダーをテストすることにしましたstring
(->文字列を含むファイルを作成し、それをbyte
配列に読み込みます)
結果は問題ありませんでした: 'Hello' はbyte
配列内の 'Hello' のままであり、上記の提案された 'olleH' の例とは異なります。
繰り返しになりますが、一言で言えば:
ファイルへの 2 進数 (10000000 00000000 00000000) の書き込みは正常に機能します。
同じ 2 進数をbyte
配列に読み込むと、次のようになります。
[0]00000000
[1]00000000
[2]10000000
ファイルの読み取りはstrings
同じままであるため、問題になることはありません。
BUT:byte
配列を解釈して元の変数 (long、double...) に戻すと、正しい結果が返されます。
bytes
したがって、私の見解では、変数の が間違った順序で格納されているように見えます。
これは本当ですか?もしそうなら、私の見解ではIEEE 754に違反しているように見えるので(しかし、それは明らかに機能します)、なぜこのように行われるのですか?
そして、この問題に対する答えを何時間も検索した後もまだ混乱しているため、ここに何かが欠けている場合は修正してください...