metanest / numo-lapack Goto Github PK

intを使うことが多いと思われるような場所でsize_tを使っているのは意図的か？

solveは入力のAの配列を確かに壊しているのだが（printfで確認）元のNArrayは壊れない。eigenでは元のNArrayが壊れる。違いはどこから来ているのか？

プレフィックスのxyyのyyの部分が、GE（密配列一般）は実数型と複素数型で共通だが、
一部の関数では対応する関数の間でSYとHEのように共通でないものがあるが、どうするか？
（numpy/scipyでは複素数のほうに寄せている）

現状では、エントリとなるメソッド名など、共通な名前は複素数のほうに寄せ、実装のコード内で
テンプレートを使って分けられる部分については分けている。

fortran_integer は narray.h の中で typedef int fortran_integer; のように定義されている。
（従って「その環境におけるint」型となる）
たいていは Numo::Int32 が、それに対応する型であろうが、そうでない環境もある可能性はあり、
それに対応させるには？

gelsのように、第一引数で入力について転置行列（複素数の場合は随伴行列）を
選べる場合もあるが、そういうのを積極的に使うか？
（現状、使っていない）

NArrayの（内部？）APIであるna_ndloop3を使っているが、仕様がまだ固まっているとはいえない（とのこと、らしい）。
もし仮に変更があった場合にどう追従するか？　最後の手段としては現在のna_ndloop3のコピーを作ってそれを使う？

（今のところNumi::LAPACKでは、infoが非ゼロの場合のフォローを入れてない）
行列式（det）で、XgetrfによるLU分解に失敗している時のフォローを入れるか？
（numpyのdetではフォローがある）

narrayの中では定義こそあるものの使ってないようだが……？

linalgからの変更点として、eigenのworkなどの領域の確保と解放を、c_funcからc_iterの中のほうに移動してある。
イテレーションを並列化するような場合に、共有だと妨げになるのではないか、という考えからだが、これで良いのか？

変数の宣言順などをもう少しコードが溜まったら統一
（後から追加する時、どれを見ても参考になるように）

既存の matmul, solve, eigen について、名前をよりLAPACKの関数名に近い直接的なものに変更

テンプレートとしては

ctype という名前は、C言語における型、という意味で

• 単に ctype は dcomplex のようにテンプレートの展開対象の型になり
• real_ctype は double のように、その型に対応する実数の型になる

Cコード中では

• dtype テンプレートの展開対象の型（つまり、テンプレートでは ctype）
• ctype テンプレートの展開対象に対応する複素数の型（テンプレートでは complex_type ）
• rtype テンプレートの展開対象に対応する実数の型（つまり、テンプレートでは real_ctype ）

特に性能の点で重要なleading dimensionへの対応をどうするか？
LDAなどにはNArrayの実サイズを入れ、計算対象の部分行列のサイズをキーワード引数MとかNとかで渡す？
（NArrayのNA_LOOP_ITERの.stepはどういう値が入ってるのか？）

solveの中でコピーが必要な場所があってmemcpyを使っているがそれでOKか？

どうする？

numpy.linalg では numpy.linalg.eigh(a, UPLO='L') のようにして、振舞にちょっとしたバリエーションが
あるためにオプショナルな引数がある関数がある。
似たようなものを Numo::Linalg で作ろうとすると、Numo::LAPACK の method_missing 中にある
ディスパッチ手続きの中で nary_mathcast を呼んで型チェックをしているため、そこでエラーになってしまう。

nary_mathcast の動作にも微妙に疑問があるかも？
（ m(a, b, c) のように引数があった場合、a と b との結果を type に得るがそれを捨てて、a と c との結果を
返すのだが...？）

ワークエリアの確保など、他にも変更可能な箇所がある

（Ruby本体にはEnumerable#sumとして2.4で入るが）Kahan summation algorithmのような
高精度のsumは要るか（誤差を蓄積させることで、近似的に倍々精度の計算をして、情報落ちによる
「積み残し」を避けるアルゴリズム）？

gesvやgelsのような、引数にNRHSがある関数の仕様をどうするか
（現状、gesvでは入力のディメンションを見て特別扱い、gelsでは1固定、としている）