Numpy: np.left_shiftおよびnp.right_shiftはnp.uint64スカラータイプで失敗します（Trac＃1931）

_ @charrisは2011-08-13_に書き込みました

これは、シフト番号が符号付き型として変換され、uint64を保持するのに十分な大きさの符号付き整数型がないためです。 シフト演算子は特殊なケースにする必要があります。ハードウェアが不要なビットをマスクするため、Intelでも失敗する可能性があります。つまり、int32の場合、下位5ビットのみが調べられます。

_tracユーザーparejkojは2012-07-27_に書き込みました

私は次のラムダでこれを回避することができました：

lshift = lambda x,s: np.uint64(x)*np.uint64(2**s)

これは機能しますが、理想的ではありません。 これをnumpyで修正すると、非常に便利です。

それは5年後です...これは重要な問題ではありませんか？ 符号なし整数は、シフトについて曖昧であってはなりません。

より簡単な回避策は、シフトに符号なし整数を使用することです。

np.uint64(5) << np.uint64(1)

上記の@charrisのように、問題はdtypeを均一にする方法にあります。 一般的に修正するのはそれほど簡単ではありませんが（＃5668も参照）、おそらくシフト演算子は特殊なケースにすることができます。 （PRは歓迎しますが、前述のように、これは簡単なことではありませんが、ufucの内部ループがどのように決定されるかを公正に理解する必要があります...）。

より簡単な回避策は、シフトに符号なし整数を使用することです。

np.uint64（5）<< np.uint64（1）

...これは、numpy整数を操作していることがわかっている場合は機能しますが、一般的なコード（特に、別のモジュールで既に記述されていて制御できないもの）を使用している場合は次のようになります。

def f(x):
    return x | (x >> 1)

その場合、通常のPython整数型とnp.uint64型の両方で機能させることはできません。

私はこれが些細なこと（私のスキルセットよりもはるかに高い）であると述べようとはしていませんが、それは優先度が高いはずだと思います。

@ jason-s-問題が非常に厄介であることに同意します...悲しいことに、ufuncが内部でどのように機能するかについて十分に精通している人はそれほど多くありません...

おそらく、一般的なufunc機構に依存する代わりに、メソッドのシフトに少なくとも特殊なケースのスカラーを使用することができます。 @charris ：これはあなたが考えていたものでした（6年後にそれを覚えているなら;-)。

＃8002も参照してください。

個人的には、すべてをやり直すことができれば、すべてのキャスティング/強制をやり直して、numpyキャスティングが本質的にCキャスティングのように動作し、Cに存在しない場合はCキャスティングの精神に従うようにします。ルールはちょっと奇妙で時々混乱します（例えばuint64 + int64からfloat64への変換）。 しかし、これについてはリストでたくさん議論してきました。変更するのは難しいようです。

このような状況に遭遇したとき（そこにある私のコメントを参照）、すべての値をnp.uint64でラップするだけです。