ここでエンディアンが必要なのはなぜですか？

Question

私はsource-codeを読んでいます。これはzipファイルをダウンロードし、データをnumpy配列に読み込みます。コードのMacOSとLinux上で動作すると仮定し、ここで私が見る抜粋です。

def _read32(bytestream): 
    dt = numpy.dtype(numpy.uint32).newbyteorder('>') 
    return numpy.frombuffer(bytestream.read(4), dtype=dt) 

この機能は、次のコンテキストで使用されます。

with gzip.open(filename) as bytestream: 
    magic = _read32(bytestream) 

ここで何が起こるか見ることは難しいことではありませんしかし、私はnewbyteorder('>')の目的に困惑しています。私はdocumentationを読んで、エンディアンが何を意味するのか知っていますが、なぜ開発者がnewbyteorderを追加したのか理解できません。ソースページに記載されたデータがダウンロードされているためだ

Answer 1

は、ビッグエンディアン形式である：http://yann.lecun.com/exdb/mnist/

ファイルのすべての整数はほとんどの非Intelが使用さMSB最初の（高 エンディアン）形式で保存されていますプロセッサ。 Intel プロセッサとその他のローエンドマシンのユーザーは、 ヘッダーのバイトを反転する必要があります。

Answer 2

これは、システムのネイティブバイトオーダーに関係なく、結果の配列から正しい順序でバイトが解釈されるようにする単なる方法です。

デフォルトでは、組み込みのNumPy整数dtypesは、システム固有のbyteorderを使用します。たとえば、私のシステムはリトルエンディアンなので、dtype numpy.dtype(numpy.uint32)を使うだけで、ビッグエンディアンのバイトでバッファから配列に読み込まれた値は正しく解釈されません。

np.frombufferは、特定のバイトオーダにあることがわかっているバイトを受信する場合、newbyteorderを使用してdtypeを変更することをお勧めします。これはdocuments for np.frombufferに記載されている：

注意

バッファは、マシンバイト順ではなく、データを持っている場合、これは例えば、データ型の一部として指定する必要があります。

>>> dt = np.dtype(int) 
>>> dt = dt.newbyteorder('>') 
>>> np.frombuffer(buf, dtype=dt) 

結果の配列のデータはバイトオーバではなく、 が正しく解釈されます。