Numpy: clangでコンパイルされたnp.float32 .__ mul__による無意味なRuntimeWarning

numpy.float32('1.5').__mul__(x) 、 __add__ 、 __sub__同じ画像。

このタイプのエラーは、 nanまたはinfinityを含む配列によく見られます。 np.array(x)は何を返しますか？

@ eric-wieser： array(x, dtype=object)返し、警告はありません。

np.multiply(np.float32('1.5'), x)は同じ警告を出しますか？

numpy.multiply(numpy.float32('1.5'), x)は同じ警告を出します。

type(x).__rmul__(numpy.float32('1.5'), x)どうですか？

また、 warnings.filterwarnings('error')実行できる場合は、完全なスタックトレースを取得します

type(x).__rmul__(numpy.float32('1.5'), x)

TypeError: descriptor '__rmul__' requires a 'sage.structure.element.Element' object but received a 'numpy.float32'

x.__rmul__(numpy.float32('1.5'))は問題なく通過します。

rmulがどのように機能するかを忘れたようです。 私はtype(x).__rmul__(x, numpy.float32('1.5'))を意味しましたが、 xが本当に奇妙でない限り、それはx.__rmul__と同じことをすることを想像します

これも失敗しますか？ np.multiply(np.array(1.5, dtype=object), x) （今回はfilterwarningsでお願いします）

type(x).__rmul__(x,numpy.float32('1.5'))は警告なしに通過します。

ちなみに、 warnings.filterwarnings('error')設定しても、何も面白いことはありません。

---------------------------------------------------------------------------
RuntimeWarning                            Traceback (most recent call last)
<ipython-input-50-b3ece847d318> in <module>()

sage: np.multiply(np.array(1.5, dtype=object), x)
---------------------------------------------------------------------------
RuntimeWarning                            Traceback (most recent call last)
<ipython-input-52-706823a0b5a2> in <module>()
----> 1  np.multiply(np.array(RealNumber('1.5'), dtype=object), x)

RuntimeWarning: invalid value encountered in multiply

うーん、セージは私がそこで予期していなかったことをしました。 float('1.5')同じ動作だと思いますか？

さて、これが私が起こっていると思うことです：

• numpyはufuncのオブジェクトループを正しく使用しており、 PyNumber_Multiply呼び出すだけです。
• sage 、何かがFPUのエラーフラグを設定しています（セージのバグ？）
• numpyは、ufuncの終了時に通常のfpuフラグチェックを実行しており（オブジェクトループのバグ？）、 sage残したエラーを見つけています。

sage: float(1.5).__mul__(x)
NotImplemented
sage: np.float(1.5).__mul__(x)
NotImplemented
sage: np.float32(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float64(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

互換性の理由からnp.float is floatは注目に値します

np.float32(1.5).__mul__(x)がNotImplemented返さないのはなぜですか？

オブジェクトループでnp.multiplyとして処理できることがわかっているため、そのループ内でfloat * xを使用して再試行します。 残念ながら、そのループのラッパーは、sageによって設定されたFPUフラグを取得しています。

よく見ると、 x.__rmul__がまだスタックの奥深くで呼び出されていることがわかります

sage: np.float32(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float128(1.5)*x
1.50000000000000*x
sage: np.float64(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

したがって、 np.float128は問題ないように見えますが、

sage: np.float128(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

これは変です。 おそらく（gccでは見られないので）コンパイラのバグですが、どこにありますか？

FPUフラグは何らかの理由でclangに設定されていますが、sageコード内のgccには設定されていないようです。 Numpyはそれについて騒ぐことのせいですが、そもそもそれを設定したことのせいではないかと私は強く疑っています。

残念ながら、 numpyは、FPUフラグを明示的に要求する方法を公開していません。これは、sage内で問題を二分するのに非常に役立ちます。

私はこれが同じ警告を引き起こすと思います（そうするためにnumpy1.12が必要だと思います）

mul = np.vectorize(x.__rmul__)
mul(float('1.5'))

まったく同じではありませんが、近いです：

/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/numpy/lib/function_base.py:2652: RuntimeWarning: invalid value encountered in __rmul__ (vectorized)
  outputs = ufunc(*inputs)
array(1.50000000000000*x, dtype=object)

OK、いいですね、これはnp.float32またはnp.float64に固有のものがないことを示しているようです。ここで警告を生成するための、より一般的なnumpyメカニズムです。

コンパイラの作者がそれをバグと見なすかどうかはわかりません。 警告が機能する方法は、プロセッサが追跡するいくつかの魔法のステータスフラグがあり、対応するイベントが発生するたびに自動的に設定されます。 Numpyは、計算を開始する前にそれらをクリアし、最後に再度チェックします。 したがって、これらのポイントの間のどこかで、clangによって生成されたアセンブリは、NaNを含む計算を実行しています。 しかし、追跡するのは難しく（実際のフラグ設定は完全にハードウェアで行われるため）、ほとんどの場合、コードがfpuフラグにどのように影響するかについて心配する必要はありません。 （Libmの実装も、これらのフラグを設定するかどうかについて一貫性がないことで有名です。）また、正確な結果は、生成される正確なasmに大きく依存するため、特定の構成でのみ表示され、他の構成では表示されないのは当然です。

うん、それは私の疑いを確認し、デバッグする方法を提供します。 このコード

def check_fpu(f):
    @functools.wraps(f)
    def wrapped(*args, **kwargs):
        excluded = list(range(len(args))) + list(kwargs.keys())
        fvec = np.vectorize(f, excluded=excluded)
        return fvec(*args, **kwargs)
    return wrapped

Python関数に適用すると、警告をそのコードのチャンク内に分離できます。

つまり、それがまったく起こっているのはかなり奇妙です。 コンパイラは通常、理由もなくNaNを発明して破棄することはありません。

それを追跡しようとしている場合は、おそらくそれらの多項式の乗算を実装するsageのコードを確認する必要があります。おそらく、奇妙なフラグ設定が常に行われている可能性があり、numpyの唯一の関与はそれを表示することです。 。

numpyがオブジェクトループでこれらのフラグをチェックしようとさえすべきではないというかなり良い議論もあります。 （または、整数ループですが、整数オーバーフローを報告する方法はやや粗雑で、fpuフラグを使用するため、注意が必要です。）numpyがここで実行できるのはそれだけです。

check_fpu()にはタイプミスがあり、 fvec = np.vectorize(f, excluded=exclude)ある必要があります。
そして、私たちはpython2を使用しています： import functools32 as functools 。

functools.wrapsはPython 3を必要としませんか？

setattr()呼び出しでpython2のfunctoolsを使用すると、エラーが発生します

AttributeError: 'method-wrapper' object has no attribute '__module__'

ええ、FPUフラグを設定しているのはRealFieldの係数の算術演算を実装している多倍長ライブラリだと思います。 基盤となるライブラリは、さまざまな状況のそれぞれでnumpyと同じコンパイラでコンパイルされていますか？ それとも、numpyだけが別のコンパイラで再構築されていますか？

ええ、RealFieldの係数の算術演算を実装している多精度ライブラリなら何でもいいと思います

それは記録のためのMPFRです。

Sagemathをclang + gfortran（主にOSXとFreeBSD、clangがプライマリコンパイラであるプラットフォーム）に移植して、OSXでの構築と実行がより簡単かつ高速になるようにします（FreeBSDは、同じような環境を実現するためのツールです。 OSXとAppleハードウェアの煩わしさ）。

ここで報告するすべての比較は、gcc / g +++ gfortranではなくclang / clang +++ gfortranを使用した完全なビルドに関するものです。

ラッパーは、 x.__rmul__がFPUフラグを設定することを示しているようです

check_fpu(x.__rmul__)(np.float32('1.5'))

警告を出力しますが、 x.__rmul__(np.float32('1.5'))は出力しません。

確かに-私の仮定は、 x.__rmul__がPythonで書かれており、そのソースコードを二分して、どのビットがフラグを具体的に設定しているかを見つけることができるというもの

x.__rmul__はCythonにありますが、それでも調査するための小さなコードです。

警告をエラーに変更する簡単な方法がある場合は、トレースバックを取得します（Cythonはエラーのトレースバックを生成しますが、警告のトレースバックは生成しません）。

@jdemeyer IMHO numpy警告は、コードパスのかなり後の方で発行されます。つまり、割り込みセットではなく、FPUフラグの明示的なチェックの結果です。

numpyは、この警告をエラーに変更するためのインターフェイスを提供しますが、バックトレースをまったく行わずに、メインのiPythonインタープリターループに戻るだけです。

@jdemeyer FPUフラグが立てられた場合、 cysignalsからのsig_on() / sig_off()間のCythonコードは例外をスローしますか？ それとも旗次第ですか？

cysignalsは、 SIGFPEが発生した場合に例外をスローします。これは、FPU構成によっては、FPUフラグが発生した場合に発生する可能性があります。 しかし、デフォルトではそうではありません。

同様の警告： RuntimeWarning: invalid value encountered in greaterは
np.float64(5)>eから来ています。 ここで、 eは、自然対数2.71828 ...の基数を指定するSagemath定数です。したがって、これをTrueに評価する方法では、「変換」する必要があります（確かに、e "は知っています「その数値近似、それは数値に対してe.n() ）です。
この概算は、すでに前述したタイプRealFieldです（したがって、この警告は密接に関連している可能性があります）。

繰り返しますが、問題は、 np.float64(5)>eを評価するためにnumpyは何をするのかということです。
または同等に、同じ警告がnp.float64(5).__gt__(e)からポップアップするので、そこから開始することもできます。

type(e)はsage.symbolic.constants_c.Eことに注意してください。 それは基本的にいくつかの（ほぼ）ダミークラスです
Sagemathのシンボリック式のラッピング（ SR ）。

np.float64(5).__gt__(e.n())またはnp.float64(5)>e.n()からの警告はありません。
eをpi置き換えた場合（明らかなpi.n()==3.1.415... ）、基本的に同じ（同じ警告/警告パターンなし）が発生します。
piタイプはSR 、つまりsage.symbolic.expression.Expressionです。

答えはここでも同じです-numpyはオブジェクトループでnp.greaterを呼び出します。 最下位レベルでは、 e.__lt__(5.0)を呼び出します。 しかし、もう一度、前後のFPUフラグをチェックし、何かが間違っていることに気づきます。

ほとんどのndarray算術/論理演算子（ -とdivmodを除く）はufuncsに委任します。 セージオブジェクトで呼び出されると、これらのufuncに対してO （オブジェクト）ループが呼び出されます。 これらのオブジェクトループは配列（この場合は0d）をループし、要素に対して通常のpython演算子を実行しますが、実行する場合はFPUフラグをチェックします。

もう一度、セージはこれらのフラグを設定しています。 おそらくこれはバグの兆候であり、おそらくそうではありません。

numpyがこれらのケースのfpuフラグをチェックするべきではないという良い議論があると思います。 @njsmith 、オブジェクトタイプのチェックを削除する必要があると思いますか？

実際のところ、 e.__lt__(5.0)はシンボリック式です。

sage: type(e.__lt__(np.float32(5.0)))
<type 'sage.symbolic.expression.Expression'>
sage: e.__lt__(np.float32(5.0))
e < 5.0
sage: bool(e.__lt__(np.float32(5.0)))  # this is how it's evaluated
True

したがって、最終的に呼び出されるかどうかは本当に疑わしいです。 True取得するcheck_fpuラッパーは警告を出力しません。つまり、次のように機能します。

sage: check_fpu(e.__lt__)(np.float32(5.0))
e < 5.0

fpectl Pythonモジュール（FreeBSDでは完全ではありませんが多少壊れています）を使用して、Sagemathの問題を特定のC拡張機能に特定することができました。 なんとかインストールできたら、実はとても速かったです。

IMHO fpectlは非常に便利なので、修正する必要があります。 コンパイルされたコンポーネントの粒度が向上するため、 np.seterr()代わりに、または

fpectlのアプローチとnp.seterrの違いは次のとおりです。

np.seterrはufuncループを実行し、フラグが設定されているかどうかを確認します。

fpectlは、フラグの1つが設定される操作が発生するたびに、ハードウェアが割り込みを発生させ、カーネルがこれをプロセスに配信されるSIGFPEに変換し、インストールするようにするための魔法を実行します。 longjmpがシグナルハンドラーから直接エラー処理コードに入るSIGFPEハンドラー。

fpectlアプローチのいくつかの欠点は、次のとおりです。（a）Windowsではまったく機能しない、（b）これらのフラグのいずれかを内部的に設定してからクリアするコードを中断する（これは合法であり、それを行うlibmがあると思います）、（c） longjmpは非常に壊れやすいです。 基本的に、実行するたびにセグメンテーション違反のリスクがあります。 それは確かに、任意のユーザー定義のufuncの一般的な解決策にはなり得ません。

これらすべてを考えると、numpyが切り替わるとは思わない。

いずれにせよ、元の問題は解決されたようですので、これを閉じてください。 seterr変更を主張したい場合は、新しい問題を開いてください。

いずれにせよ、元の問題は解決されたようです

オブジェクトループのFPUフラグのチェックを無効にしたくないのは確かですか？ それはnumpyへのかなり賢明な変更のように思えます。

@ eric-wieser：ああ、それは面白いアイデアですね。 多分それはそのための問題を開く価値があります:-)。 ただし、「正しいこと」はかなり複雑です。理想的には、オブジェクトのdtype（ユーザーのdtypeを考えてください）を特別なものにするべきではなく、整数ループもそれを使用しないでください（これは、チェックする一部のアーキテクチャでの実際の最適化である可能性があります） / FPUフラグのクリアは非常に遅いです）が、整数ループは整数エラーを明示的に通知する方法を必要とします。これは現在、FPUフラグを明示的に設定することによって行われます...これが簡単に低い場合であるかどうかはわかりません-ぶら下がっている果物？

または、私は誤解しましたが、セージは問題を特定しただけで、実際に修正するにはまだ多くの変更が必要ですか？

@njsmith ：Windowsでは動作しないと言う理由がわかりません。 （ただし、これはC99以前の時代には正しいでしょう）。 最新のFPU処理関数（fenv）は、CコンパイラーがC99標準に準拠するとすぐに使用可能になります。 fenvとは別に、必要なのはsetjmp / longjmp（これも標準のC機能）だけです。

また、通常の操作中にFE例外の1つを引き起こすlibmについて聞いてみたいと思います。
（バグとして分類されていない限り）。

@dimpase ：C99で指定されていないSIGFPEサポートも必要です。 （まあ、C99はSIGFPEがあるべきだと言っていますが、それはゼロ除算のためです–浮動小数点例外にフックする方法を指定していません。）とはいえ、私は覚えていなかったようですが、Windowsはシグナルをサポートしていません。MSVCRTは構造化例外処理を使用してSIGFPEをエミュレートし、特定のfp例外に対してそれを有効にする非標準の_control_fp関数を提供するため、Windowsサポートは実際には障壁ではありません。 OTOH longjmpは非常に正当な理由がなければ絶対に起こらないので、それほど重要ではありません:-)

そしてFWIW、libmがFE例外を引き起こし、それを再びクリアした場合、なぜ彼らがそれをバグと見なすのかわかりません。 そのような実装が存在するかどうかはわかりませんが、それはもっともらしいです、そしてそれらが存在する場合、私たちが見つける方法はb / cです誰かがプラットフォームXでnumpyが壊れていると私たちに言いますそして唯一の修正は変更を元に戻すことですあなたが提案した。

以前のコメントの最後に私が尋ねた質問に答えてもらえますか？

@njsmith ：libm（またはその他のユーザーコード）がFE例外を発生させて処理する必要がある場合、独自のFE例外ハンドラーを設定し、前の例外ハンドラーを保存して、終了時に前の例外ハンドラーを復元します。
したがって、基礎となるコードがルールに従って再生されていても問題はありません。

これに対するMSのサポートに関しては、Visual C（++）2013以降からfenv.hが出荷されています。
これは特にsetjmp / longjmpで役立つことを意図しています（内部でどのように正確に行われるかは、それほど心配する必要はありません、私は願っています）。

numpyのRuntimeWarningについて：

• ユーザーコードがFPフラグを使用して高速かつ緩く再生できると思われる場合、これらの警告はせいぜいオプションである必要があります。
• そうでなければ、それらは標準に保つことができますが、少なくともそれらが有用であるためには、それらが由来する場所の底に到達する方法が重要です。 （改善） fpectlは、後者を実現するための簡単な方法です。 外部ツール（すべての命令の後に何かをチェックするためにコードをインストルメント化できるデバガーなど）を使用することは、より難しく、遅く、エラーが発生しやすくなります---たとえば、バグが最適化されたバイナリでのみポップアップすることは珍しいことではありません。十分にデバッグ可能なバイナリでそれを見つけようとするとすぐに消えます。
• いずれにせよ、RuntimeWarningはオフにできるはずです。

Sageのこの問題に関して-まだ修正中です（うまくいけば、 MPFRのいくつかの問題に限定されます）。

申し訳ありませんが、これは輪になっていて、他のことに移る必要があるので、fenv / sigfpeの問題で何か新しいことが起こらない限り、これがこのトピックに関する私の最後のメッセージになります。 （賢者のバグのためにnumpyがする必要があることがあるかどうか私はまだ興味があります）。

libm（または他のユーザーコード）がFE例外を発生させて処理する必要がある場合、libmは独自のFE例外ハンドラーをセットアップし、前のハンドラーを保存します。

あなたが提案しているのは、通常はシグナルハンドラーを起動させない操作を実行し、シグナルハンドラーを起動させる非標準モードでプロセッサを構成することです。 コードがこの操作を実行し、シグナルハンドラーをまったくトリガーしないことを期待することは完全に合理的です。

これに対するMSのサポートに関しては、Visual C（++）2013以降からfenv.hが出荷されています。
これは、setjmp / longjmpで役立つことを特に意図しています。

あなたがここで何について話しているのか理解できません。 Afaict、fenv.hの標準機能は、numpyスタイルの機能を実装する場合にのみ役立ち、MSは標準に準拠しています。 setjmp / longjmpで使用できる関数はまったくありません。

ユーザーコードはFPフラグを使用して高速かつ緩く再生できるため、これらの警告はせいぜいオプションである必要があります。

中間計算によって設定されたフラグを注意深くクリアすることは、それらをすばやく緩くプレイすることとは正反対です。 また、警告はオプションです。

彼らが由来する場所の底に到達する方法は、彼らが有用であるために重要です。 （改善された）fpectlは、後者を実現するための迅速な方法です。

あなたは文字通り、この種の問題をデバッグするためにSIGFPEを必要とする10年ほどの最初の人です。そして、賢明なバグのコメントをもう一度見てみると、実際にはfpectlが機能していなかったようです。 コアダンプが発生することは想定されていません。 （cysignalsがfpectlコードをオーバーライドしているように見えるため、実行されません。）

これが再び発生した場合は、1回のC呼び出しを行ってSIGFPEを有効にしてから、デバッガーを使用してスタックトレースを取得する必要があります。 スタックトレースを取得するためにデバッグビルドは必要ありません。 あなたがする必要があるのはシンボルを取り除くことだけではありません。 そしてねえ、これが再び発生した場合に備えて、今ではわかっています。

これはデバッグするのに本当にイライラすることだと理解していますが、これが何を達成するかを明確に説明することさえできない場合、他のプロジェクトが基本的なインフラストラクチャを変更または維持する必要があると主張することは役に立ちません。 （私は実際、ここで何かを変更することで、この種のバグをより早く見つけるのにどのように役立つと思うかわかりません。 longjmpの全体的なアイデアは、あなたが望むより正確な情報を破壊することです。）

最後に、それはclangCコンパイラの長年のバグに要約されることが判明しました。 基本的に、 double特定の範囲では、

unsigned long a;
double b;
...
a = b;

FE_INVALID （場合によってはFE_INEXACT ）を発生させます。 ところで、これは他のタイプのフロートデータにも影響を及ぼしています。 優れたMPFR（MPFRはダブルを任意の精度のフロートにコピーする必要があります）人々は回避策を提供し、これをセージのために修正しました。

ちなみに、関連するさらに長い間（2010年以降、12個の閉じた複製がある）clangバグ8100は、現時点でfpectl適切に機能させるためにclangのfenv.hを使用する見込みはないと述べています。 。 Clangは、この点でC99に完全には準拠しておらず、非常に恥ずかしがり屋です。

numpyがそれについて何かしたいかどうかわからない。 おそらく、 RuntimeWarningは単にコンパイラのバグが原因である可能性があるというコメント（「clangbug 8100」を引用、これは非常に顕著な例です）が役立つかもしれません。

バグ8100は関係ありません。 これは、C99プラグマが浮動小数点最適化を無効にするためのものであり、主流のコンパイラーはそれらをサポートしていません。 numpyは（ほとんど）とにかく機能するようです:-)

バグ8100の精神は、clangがFP操作が正しくコンパイルされていることを気にしないことです。 弁護士は同意しないかもしれませんが。 :-)

OK、すでに述べたバグ17686は確かに関連しています。