これは実装の問題というよりはむしろ「哲学」の問題かもしれませんが、Frobenius Norm はベクトルで動作するべきではありませんか? ソース:ウルフラム
現在、numpy の Frobenius Norm はベクトルを受け入れません。
import numpy as np
a = np.random.rand(10, 1)
b = np.squeeze(a)
print(np.linalg.norm(a, 'fro'))
print(np.linalg.norm(b, 'fro'))
結果は次のとおりです。
1.7594677278427366
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
//anaconda3/lib/python3.7/site-packages/numpy/linalg/linalg.py in norm(x, ord, axis, keepdims)
2515 try:
-> 2516 ord + 1
2517 except TypeError:
TypeError: can only concatenate str (not "int") to str
During handling of the above exception, another exception occurred:
ValueError Traceback (most recent call last)
<ipython-input-18-2ace847024a5> in <module>
3 b = np.squeeze(a)
4 print(np.linalg.norm(a, 'fro'))
----> 5 print(np.linalg.norm(b, 'fro'))
<__array_function__ internals> in norm(*args, **kwargs)
//anaconda3/lib/python3.7/site-packages/numpy/linalg/linalg.py in norm(x, ord, axis, keepdims)
2516 ord + 1
2517 except TypeError:
-> 2518 raise ValueError("Invalid norm order for vectors.")
2519 absx = abs(x)
2520 absx **= ord
ValueError: Invalid norm order for vectors.
これは'fro'
kwarg の処理のバグのようです。
>>> print(np.linalg.norm(b))
1.7547099704258247
ord
kwarg が None の場合、Frobenius ノルムがデフォルトであることに注意してください。
xref gh-14719 および gh-14215: 私たちは一般的なケースを廃止することを考えましたが、大きな抵抗はなかったものの、いくつかの抵抗があったため、先に進めませんでした。 そして、他のいくつかのパッケージはそれをそのように定義しています。 問題は、ここで正確にどこに行くかを決めることです...
Ross が私に指摘したように、私がリンクした issue/PR は接線方向にのみ関連しており、これは明らかに"fro"
処理のバグです。
kwarg 処理 (および付随するテスト) のバグに対処するための PR は大歓迎です! ナイスキャッチ@TNonet
これは私の最初の問題なので、適切なテストとプルリクエストを作成するためのリソースはありますか?
(また、numpy リポジトリを複製して setup.py を実行する場合、numpy をインポートするときにどの numpy バージョンを使用するかをどのように確認しますか?)
ord が 'fro' の場合、以下の 2512 ~ 14 行目であると私は主張します。
次のように変更する必要があります。
if ((ord is None) or
(ord in ('f', 'fro')) or
(ord == 2 and ndim == 1)):
n 番目の配列には、各要素の正方形を自然に合計する Forbenious Norm があることに誰もが同意すると仮定します。
問題は実際にはコードのさらに下にあります。最初に受け取ったエラーからのトレースバックをたどれば、問題のあるビットを見つけることができるはずです。
#14719 と #14215 の議論で述べたように、2 次元を超える動作は別の問題です - この PR を kwarg 処理のバグに限定できれば最善です。
Re:テスト/貢献のためのリソース: NumPyの貢献ガイドラインを見てnumpy/linalg/tests/test_linalg.py
linalg テストを見て、テストがどのように定式化され、どこで追加のテストが適切かを知ることもできます。 それが役立つことを願っています!
最も参考になるコメント
問題は実際にはコードのさらに下にあります。最初に受け取ったエラーからのトレースバックをたどれば、問題のあるビットを見つけることができるはずです。
#14719 と #14215 の議論で述べたように、2 次元を超える動作は別の問題です - この PR を kwarg 処理のバグに限定できれば最善です。
Re:テスト/貢献のためのリソース: NumPyの貢献ガイドラインを見て
numpy/linalg/tests/test_linalg.py
linalg テストを見て、テストがどのように定式化され、どこで追加のテストが適切かを知ることもできます。 それが役立つことを願っています!