参照。 ＃9930、＃20053、＃23552。 ベスト！

参照していただきありがとうございます。 この問題は、APIの改良よりもgemmスタイルのメソッドの追加に関係していると思いますが、それでも＃9930とあまりにも類似していると思われる場合は、閉じることができます。

出発点として、 _generic_matmatmul!にgemm APIを持たせるためのサポートはありますか？ 現在のメソッドはα=1とβ=0使用するだけで実装されるため、これはかなり単純な変更であり、純粋に付加的/非破壊的です。 PRできます。 私はおそらくこのバージョンと同じように行きます（そのバージョンでは、必要がなかったのですべてのトランスポーズをカットしました。ここではそれを行いません）。

はい。 それは良いスタートになるでしょう。 ただし、引数の順序を考慮する必要があります。 もともと、BLASの順序に従う方が自然だと思っていましたが、現在の3つの引数A_mul_B!も当てはまる、最初に出力引数を持つことについてはかなり一貫しています。 さらに、すでに指摘したように、3つの引数のバージョンはα=1とβ=0の5つの​​引数のバージョンに対応し、デフォルト値の引数は最後になります。 もちろん、これに必ずしもデフォルト値の構文を使用する必要はありませんが、ここで使用することは理にかなっています。

なぜ一般的なgemm関数を導入しないのですか？

はい。 それは良いスタートになるでしょう。 ただし、引数の順序を考慮する必要があります。 もともと、BLASの順序に従う方が自然だと思っていましたが、現在の3つの引数A_mul_B！にも当てはまる、最初に出力引数を持つことについてはかなり一貫しています。 さらに、すでに指摘したように、3つの引数のバージョンはα= 1およびβ= 0の5つの引数のバージョンに対応し、デフォルト値の引数は最後になります。 もちろん、これに必ずしもデフォルト値の構文を使用する必要はありませんが、ここで使用することは理にかなっています。

いいですね。 ＃9930で、実際の引数の順序とメソッドの名前変更についての議論を続けることができます。 私は現在おこうので、これは、よりわずか5引数バージョンが利用可能になる程度であるAx_mul_Bx!(α,A,B,β,C)インターフェイスを。

一般的なgemm関数を導入してみませんか？

上記の変更に加えて、 _generic_matmatmul!名前をgemm!に変更することを提案していますか？

明確にするために、ディスパッチする怠惰な転置/随伴型とともに、単一のメソッドmul(C,A,B,α=1,β=0)を使用する必要があると思いますが、それは別のPRになります。

一般的なgemm関数を導入してみませんか？

gemmはジュリアの誤称だと思います。 BLASでは、 ge部分は、行列が一般的であること、つまり特別な構造がないこと、最初のmが乗算であること、リストmが行列であることを示します。 Juliaでは、 ge （一般）部分が最後のm （マトリックス）と同様に署名にエンコードされているので、 mul!と呼ぶべきだと思います。

SparseArrays.jlの表記mul!(α, A, B, β, C)です

https://github.com/JuliaLang/julia/blob/160a46704fd1b349b5425f104a4ac8b323ea85af/stdlib/SparseArrays/src/linalg.jl#L32

公式構文として「完成」？ そして、これはmul!(C, A, B) 、 lmul!(A, B) 、およびrmul!(A,B)に追加されますか？

私はA 、 B 、 Cを異なる順序で並べるのが好きではありません。

SparseArrays.jlの表記mul!(α, A, B, β, C)は、公式の構文として「finalised」されていますか？

いいえと思います。 もともと私はBLASに従うというアイデアが好きでした（そして順序もこれが通常数学的に書かれる方法と一致しました）が、今ではオプションの4番目と5番目の引数としてスケーリング引数を追加するのが理にかなっていると思います。

明確にするために、ある意味でオプションの引数が必要です

function mul!(C, A, B, α=1, β=0)
 ...
end

他のオプションはオプションのキーワード引数になります

function mul!(C, A, B; α=1, β=0)
...
end

しかし、人々がユニコードに満足しすぎているかどうかはわかりません。

私はユニコードに非常に満足していますが、私たちが常にASCIIオプションを持っていることを試みているのは事実であり、それはここで可能です。 αとβという名前も、BLASを知らない限り、あまり直感的ではないので、ここでは位置引数を使用する方が良い解決策だと思います。

私の意見では、より論理的な命名法は、 muladd!(A, B, C, α=1, β=1)乗算と加算を行うさまざまなBLASルーチンにマップさせることです。 （ gemm上記のようなだけでなく、例えば、 axpy場合Aスカラーです。）

mul!関数は、すべての中間結果をYに格納できる限り、任意の数の引数を取るmul!(Y, A, B, ...)ようなインターフェイスを持つことができます（ *同じように）。（オプションのkwargは、妥当なデフォルトで乗算の順序を指定できます）

mul!(Y, A::AbstractVecOrMat, B:AbstractVecOrMat, α::Number)には、2つの行列/ベクトルとスカラーの他の順列と同様に、デフォルトの実装muladd!(A, B, Y, α=α, β=0)があります。

密行列に対してmul!(C, A, B, α, β)定義するための別の投票。 これにより、密行列と疎行列のジェネリックコードを記述できます。 このような関数を非線形最小二乗パッケージで定義したかったのですが、これはタイプの著作権侵害だと思います。

また、 MixedModelsパッケージ用にmul!(C, A, B, α, β)メソッドを記述して、ちょっとしたタイプの著作権侵害に従事したいと思っていますが、そのようなメソッドがLinearAlgebraれているとはるかに良いでしょう。パッケージ。 この操作のジェネリックmuladd!メソッドがあると、私も問題ありません。

私は賛成ですが、おそらくmul!は別の名前にする必要があると思います。 muladd!は妥当なようですが、確かに提案を受け入れています。

たぶんmulinc!は乗算インクリメントですか？

たぶん私たちはaddmul!(C, A, B, α=1, β=1)ようなものを持つことができますか？

これはmuladd!形式ではありませんか？ それとも、それをaddmul!と呼ぶ背後にある考え方は、乗算引数ではなく加算引数を変更するというものですか？ 乗算引数を変更することはありますか？

lmul!やldiv! 、最初以外の要素を変更する場合があるため、通常の「muladd」順序（ muladd!(A,B,C) ）で変更できることに注意してください。 問題は、 αとβ順序を

スカラーαとβのタイプをディスパッチするオプションを実装者に任せたら素晴らしいと思いませんか？ エンドユーザーのために砂糖を加えるのは簡単です。

すでにmul!(C, A, B, α, β)落ち着き、デフォルト値はα 、 βだと思いました。 このバージョンはhttps://github.com/JuliaLang/julia/blob/b8ca1a499ff4044b9cb1ba3881d8c6fbb1f3c03b/stdlib/SparseArrays/src/linalg.jl#L32-L50で使用してい

ありがとう！ それが文書化されていればいいのですが。

すでにmul!(C, A, B, α, β)落ち着き、デフォルト値はα 、 βだと思いました。

SparseArraysはそれを使用しますが、どこでも議論されたことを思い出しません。

いくつかの点で、 muladd!名前は、乗算とそれに続く加算であるため、より自然です。 ただし、αとβのデフォルト値muladd!(C, A, B, α=1, β=0) （βのデフォルトは1ではなくゼロであることに注意してください）は、 mul!(C, A, B)に戻します。

これをmul!とmuladd!どちらで呼び出すかは、衒学と一貫性のケースのようであり、SparseArraysの既存のメソッドのケースはmul!を主張すると思います。 私のお気に入りのオスカーワイルドの引用にもかかわらず、一貫性を主張するという奇妙なケースに自分自身を見つけます。「一貫性は想像を絶する最後の避難所です。」

いくつかの点で、 muladd!名前は、乗算とそれに続く加算であるため、より自然です。 ただし、αとβのデフォルト値muladd!(C, A, B, α=1, β=0) （βのデフォルトは1ではなくゼロであることに注意してください）は、 mul!(C, A, B)に戻します。

CにInfsまたはNaNが含まれている場合、これには興味深い例外があります。理論的には、 β==0場合、結果はNaNのままです。 BLASとスパース行列コードが明示的にβ==0チェックし、それをゼロに置き換えるため、これは実際には発生しません。

true*xは常にxであるという意味で、 trueとfalseはそれぞれ「強い」1と0であるため、デフォルトがα=true, β=falseであると考えることができます。 xとfalse*xは常にzero(x)です。

lmul!も、その例外的な動作が必要です： https ：

trueとfalseは、 true*xが常にxあり、 false*xが常にzero(x)であるという意味で、それぞれ「強い」1と0です。

私はそれを知りませんでした！：

julia> false*NaN
0.0

FWIW、この操作のLazyArrays.jl構文の読みやすさにかなり満足しています。

y .= α .* Mul(A,x) .+ β .* y

舞台裏では、BLAS互換アレイ（バンドおよびストライド）の場合、 mul!(y, A, x, α, β)に下がります。

知らなかった！

これは、 im = Complex(false, true)機能させるものの一部です。

SparseArraysはそれを使用しますが、どこでも議論されたことを思い出しません。

上記のhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-365463941で説明され、異議なしにhttps://github.com/JuliaLang/julia/pull/26117で実装されました。 密集したケースにはα,βバージョンがないため、このリポジトリで決定が即座に影響を与える唯一の場所はSparseArraysます。

LinearAlgebra.BLAS.gemm!どうですか？ 5つのmul!としてもラップするべきではありませんか？

それはすべきですが、まだ誰もそれをしていません。 matmul.jlは多くのメソッドがあります。

これは上記の＃23919（コメント）で説明され、＃26117で異議なしに実装されました。

まあ、これは私の異議だと考えてください。 別の名前がいいと思います。

なぜ違う名前になるのでしょうか？ 密な場合と疎な場合の両方で、基本的なアルゴリズムは乗算と加算の両方を実行します。

これらの関数に異なる名前を付けると、 mul!(C,A,B) = dgemm(C,A,B,1,0)とmuladd!(C,A,B,α, β) = dgemm(C,A,B,α, β)ます。

私が見る唯一の利点は、実際にメソッドを分割し、 C = A*B場合にif β==0呼び出しを保存する場合です。

参考までに、インターフェイスをmatmul.jlに追加するために、＃29634で作業を開始しました。 名前と署名が決まるまでに完成させたいと思っています:)

muladd!の利点は、デフォルトのα = β = true （元の提案httpsで述べたように）で3項のmuladd!(A, B, C) （またはmuladd!(C, A, B) ？）を持つことができることです。 //github.com/JuliaLang/julia/issues/23919#issuecomment-402953987）。 方法muladd!(A, B, C)に似てmuladdのためにNumber私はそれはあなたが既に知っている場合は特に、より自然な名前だと思うので、S muladd 。

@andreasnoack以前の議論は、メソッド名ではなく、メソッドのシグネチャとキーワード引数よりも位置引数を優先することに関するもののようです。 muladd!という名前に異議はありますか？ （ SparseArraysに5つのmul!が存在することもありますが、下位互換性のあるラッパーを定義することは難しくありません。）

mul!とmuladd!両方を持つことは、前者がαとβデフォルト値を持つ後者である場合、冗長に見えます。 さらに、 add部分はBLASによって正規化されています。 muladd!で信頼できる一般的な線形代数アプリケーションを思い付くことができれば、それについて聞きたいのですが、それ以外の場合は冗長性を避けたいと思います。

また、私は強く私たちは強いゼロプロパティおくことを好むだろうfalseの議論とは別にmul! 。 IMOのβのゼロ値は、BLASの場合と同様に、現在の5つの引数mul!メソッドの場合と同様に強力である必要があります。 つまり、この動作はβタイプではなく、 mul!結果である必要があります。 代替案を扱うのは難しいでしょう。 例： mul!(Matrix{Float64}, Matrix{Float64}, Matrix{Float64}, 1.0, 0.0) 〜できました〜BLASを使用できませんでした。

BLASの動作を変更することはできませんが、floatの強いゼロの動作が_requiring_するということは、すべての実装でゼロをチェックするためのブランチが必要になることを意味します。

muladd!信頼できる一般的な線形代数アプリケーションを思い付くことができれば

@andreasnoackこれは、「_ three-argument_ muladd!申請」を意味していると思います。そうしないと、5つの引数mul!を含めることに同意しないからです。

しかし、それでもmuladd!(A, B, C)が役立つ例を思いつくことができます。 たとえば、「スモールワールド」ネットワークを構築する場合は、帯行列とスパース行列の「遅延」合計があると便利です。 次に、次のように記述できます。

A :: SparseMatrixCSC
B :: BandedMatrix
x :: Vector  # input
y :: Vector  # output

# Compute `y .= (A .+ B) * x` efficiently:
fill!(y, 0)
muladd!(x, A, y)  # y .+= A * x
muladd!(x, B, y)  # y .+= B * x

ただし、使用するために単純にラップできるので、手動でtrue書き込んでもかまいません。 安定した文書化されたAPIとして5つの引数の関数を持つことは、ここでの最も重要な目標です。

要点に戻る：

mul!とmuladd!両方を持つことは、前者がαとβデフォルト値を持つ後者である場合、冗長に見えます。

ただし、出力配列の「デフォルト値」が適切に初期化された状態で、 mul!に関していくつかの*実装されています。 Baseや標準ライブラリにそのような「ショートカット」の例があるのではないかと思います。 mul!はmuladd!ショートカットにすぎませんが、 mul!とmuladd!両方を使用するのは理にかなっていると思います。

falseのストロングゼロプロパティをmul!説明とは別にしておくことを強くお勧めします。

最初に乗算加算の5つの引数バージョンの名前について議論することに焦点を当てることが建設的であることに同意します（ mul!対muladd! ）。

行列と数値を一般的に処理するためにmuladdが必要な一般的なユースケースを求めたとき、私はうまくいきませんでした。 番号バージョンは感嘆符なしでmuladdになるので、私が尋ねたことは実際には意味がありませんでした。

あなたの例は次のように書くことができます

mul!(y, A, x, 1, 1)
mul!(y, B, x, 1, 1)

だから私はまだmuladd!の必要性を見ていません。 このケースが非常に一般的で、 1, 1を書くのが冗長すぎると思うだけですか？

ただし、出力配列の「デフォルト値」が適切に初期化された状態で、 mul!に関していくつかの*実装されています。 Baseや標準ライブラリにそのような「ショートカット」の例があるのではないかと思います。

これはわかりません。 詳しく説明していただけますか？ ここで話しているショートカットは何ですか？

だから私はまだmuladd!の必要性を見ていません。 このケースが非常に一般的で、 1, 1を書くのが冗長すぎると思うだけですか？

muladd!は、実際に何をするかについてもより説明的だと思います（ただし、おそらくaddmul!である必要があります）。

muladd!という名前に問題はありません。 第一に、私はこれのために機能する必要はないと思います、そして第二に、 muladd! / addmul!を支持してmul!を非推奨にする価値はないと思います。

このケースは非常に一般的であるため、1、1を書くのは冗長すぎると思うだけですか？

いいえ。パブリックAPIである限り、5つの引数関数を呼び出してもまったく問題ありません。 私はちょうど3つの引数バージョンだけが必要な例を挙げようとしました（それがあなたの要求だと思ったので）。

ここで話しているショートカットは何ですか？

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAlgebra/src/matmul.jl#L140 -L143

ここで定義されている*は、 mul!ショートカットと見なすことができると思います。 デフォルト値の「ちょうど」 mul!です。 では、なぜmul! addmul!をデフォルト値のmuladd! / addmul!しないのですか？

同様の「ショートカット」として定義されているrmul!とlmul!もあります。

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAlgebra/src/triangular.jl#L478 -L479

mul!廃止

議論は新しいインターフェースを追加するかどうかについてだと思いました。 新しいAPIを追加するためにmul!を非推奨にする必要がある場合、それだけの価値はないと思います。

私が考えることができる主な議論は次のとおりです。

• 概念的には、5引数形式は単なる「乗算」以上のことを行い、これをより明確に伝えます。
• 次に、 mul!(C,A,B,1,1)またはmul!(C,A,B,true,true)代わりにaddmul!(C, A, B)書くことができます。

ここで定義されている*は、 mul!ショートカットと見なすことができると思います。 デフォルト値の「ちょうど」 mul!です。 だから、なぜmulさせないでください！ デフォルト値でmuladd! / addmul!なりますか？

*は行列を乗算するデフォルトの方法であり、ほとんどのユーザーがそれを行う方法だからです。 比較すると、 muladd!使用量は*に近くなりません。 さらに、それは既存の演算子ですが、 muladd! / addmul!は新しい関数になります。

rmul!とlmul!は、通常、アウトオブプレースのmul!メソッドのデフォルト値バージョンではないため、このパターンに適合するとは思わないでください。

サイモンは、すぐ上の投稿で利点をうまく要約しています。 問題は、名前変更の追加機能（ mul!非推奨を意味する）のいずれかを正当化するのに十分なメリットがあるかどうかです。 それは私たちが同意しないところです。 それだけの価値はないと思います。

名前を変更する価値がないと言うとき、APIが完全に公開されていないことを考慮しましたか？ つまり、それはJuliaのドキュメントにはないということです。

LazyArrays.jl（および他のパッケージ？）はすでにそれを使用しているので、盲目的にsemverをフォローするのは良くありません。 しかし、それでも、他の関数ほど公開されていません。

mul!はLinearAlgebraからエクスポートされ、広く使用されているため、この時点で確実に非推奨にする必要があります。 A_mul_B!がmul!または少なくとも0.7より前に、関数の名前を変更する方がはるかに良い時期だったので、この議論がなかったのは残念です。

今のところmul!を使用して、stdlibを個別に更新できるときにLinearAlgebra v2.0の名前を更新するのはどうですか？

LazyArrays.jlは、多くの種類の行列に対して柔軟性がないため、 mul!使用しません（ StridedArrayオーバーライドすると、コンパイラの速度低下のバグが発生します）。 フォームの代替構造を提供します

y .= Mul(A, x)

私が見つけたものはより説明的です。 5つの引数のアナログは

y .= a .* Mul(A, x) .+ b .* y

mul!を非推奨にし、LinearAlgebra.jlのLazyArrays.jlアプローチに移行することに賛成ですが、それは難しいケースになります。

LowRankApprox.jlはmul!を使用しますが、LazyArrays.jlアプローチを使用するように変更して、コンパイラのバグを回避する可能性があります。

OK。 提案は2つしかないと思いました。 しかし、どうやら大まかに3つの提案がありますか？：

1. 3引数と5引数mul!
2. 3引数と5引数muladd!
3. 3つの引数mul!と5つの引数muladd!

（ muladd!はaddmul!と呼ばれる場合があります）

1と3を比較していると思っていました。 わかりました。

3つの引数mul!はパブリックAPIであり、広く使用されているため、2はまったくオプションではないと思います。 「APIが完全に公開されていない」とは、 5つの引数mul!が文書化されていないことを意味します。

はい、私の計画はmul!を保持することmul!とaddmul!は異なる動作をするため、これは価値があると思います。つまり、 addmul!(C, A, B, α, β)与えられると、次のようになります。

mul!(C, A, B) = addmul!(C, A, B, 1, 0)
mul!(C, A, B, α) = addmul!(C, A, B, α, 0)
addmul!(C, A, B) = addmul!(C, A, B, 1, 1)
addmul!(C, A, B, α) = addmul!(C, A, B, α, 1)

ただし、実際にはこの方法で実装したくない場合があります。たとえば、4引数のmul!とaddmul!別々に設定し、5引数のaddmul!を定義する方が簡単な場合があります。

addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

バンプ！

ただし、実際にはこの方法で実際に実装したくない場合があります。たとえば、4引数のmulだけの方が簡単な場合があります。 そしてaddmul！ 個別に、5引数のaddmulを定義してください！ なので：
addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

すぐに最適にやってみませんか？ そのようにしないことのポイントは、 Cの要素に一度だけアクセスする必要があるということです。これは、大きな行列の場合は間違いなくより効率的です。 さらに、5引数のaddmul!だけを定義するのに対して、4引数のmul!とaddmul!両方を別々に定義することで、コードが長くなるとは信じられません。

参考までに、LinearAlgebraの_generic_matmatmul!の実装を変更して、LazyArraysで5つの引数を取るようにしました： https ：

ここでは、経由で呼び出されます：

materialize!(MulAdd(α, A, b, β, c)) 

ただし、実際のコード（ tiled_blasmul! ）は、LinearAlgebraに簡単に変換して戻すことができます。

このプロセスをスピードアップするために何ができるでしょうか？ 私が取り組んでいることは、インプレースmul + addを備えた統合行列乗算APIから本当に恩恵を受けるでしょう

Strided.jlの最新バージョンは、5つの引数mul!(C,A,B,α,β)もサポートするようになり、可能な場合はBLASにディスパッチし、それ以外の場合は独自の（マルチスレッド）実装を使用します。

@Jutho素晴らしいパッケージ！ 次のロードマップはありますか？ 最終的にLinearAlgebraとマージする計画はありますか？

これは私の意図ではありませんでしたが、ある時点で要求された場合、私はそれに反対しません。 ただし、一般的なmapreduce機能での@generated関数の自由な使用（1つだけですが）は、Baseにはあまり適していない可能性があります。

私の個人的なロードマップ：これは主に、高レベルのパッケージ、つまり新しいバージョンのTensorOperationsや、私が取り組んでいる他のパッケージで使用される低レベルのパッケージです。 ただし、基本的な線形代数をさらにサポートすることをお勧めします（たとえば、 normをStridedView現在、Julia Baseでのnorm実装がかなり遅くなります）。 また、時間があり、GPUの操作方法を学ぶ場合は、同様に一般的なmapreducekernelをGPUArrayに実装してみてください。

これまでのコンセンサスは次のとおりだと思います。

1. mul!(C, A, B)を維持する必要があります
2. インプレース乗算には_some_5引数関数が必要です- C = αAB + βC追加します

最初に5引数関数の名前に焦点を当て、後で追加のAPIについて説明することをお勧めします（3引数および4引数addmul! ）。 しかし、これはmul!を使用して_not_から取得する「機能」であるため、混合しないのは困難です。

@andreasnoackは、上記@simonbyrneのコメントによって解決リネーム廃止/についてのあなたの関心事であるhttps://github.com/JuliaLang/julia/issues/23919#issuecomment -431046516？ 非推奨の必要はないと思います。

参考までに、実装＃29634を終了しました。 LinearAlgebra精通している人がレビューしていただければ幸いです。

すべてにmul!という名前を付ける方が簡単で良いと思います。 また、非推奨を回避します。 本当に別の名前が必要な場合は、 muladd方が適しています。

mul! APIについて議論するときに考慮すべき他の何か：

scale!が消えて、0.6-> 0.7遷移に夢中になったとき、スカラー倍算（ベクトル空間のプロパティ）とオブジェクト自体の乗算（代数のプロパティ）が非常に異なっていたので、少し悲しかったです。 ）。 それにもかかわらず、私はmul!アプローチを完全に受け入れており、スカラー乗算が可換でない場合にrmul!(vector,scalar)とlmul!(scalar,vector)できることを非常に高く評価しています。 しかし今、私は毎日、他の2つのインプレースベクトル空間演算の非ジュリアン名であるaxpy!とその一般化axpby!悩まされています。 これらもmul! / muladd! / addmul!に吸収される可能性があります。 少し奇妙ですが、 A*Bの2つの要素の1つがすでにスカラーである場合、追加のスカラー要素αは必要ありません。
しかし多分それなら、

mul!(C, A, B, α, β)

ある可能性もあります

add!(Y, X, α, β)

axpby!を置き換えます。

@andreasnoack廃止/名前変更に関する懸念は、＃23919（コメント）の上の@simonbyrneのコメントによって解決されましたか？ 非推奨の必要はないと思います。

https://github.com/JuliaLang/julia/issues/23919#issuecomment-430952179の最後の段落を参照してmul!を非推奨にする必要があると思います。

@Jutho acp(b)y!名前をadd!するのは良い考えだと思います。

＃23919（コメント）の最後の段落を参照してください。 新しい機能を導入するだけの価値はないと思います。

はい、私はそれを読み、5つの引数mul!は文書化されておらず、パブリックAPIの一部ではないと返信しました。 したがって、_技術的に_非推奨にする必要はありません。 https://github.com/JuliaLang/julia/issues/23919#issuecomment -430975159の最後の段落を参照して

ここでは、1つの署名（例： mul!(C, A, B) ）の文書化によるパブリックAPIの宣言は、他の署名（例： mul!(C, A, B, α, β) ）には適用されないと想定しています。 そうでない場合は、Juliaとそのstdlibが内部を公開しすぎていると思います。 たとえば、これはPkg.add文書化された署名です

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/Pkg.jl#L76 -L79

一方、実際の定義は

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/API.jl#L69 -L70

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/API.jl#L27 -L33

Pkg.add少なくとも1つの署名のドキュメントの存在が、他の署名がパブリックAPIであることを意味する場合、Pkg.jlは、メジャーバージョンをバンプせずに、実装の詳細のために動作を削除できません。例： Pkg.add(...; mode = :develop)はPkg.develop(...)ます; Context!へのすべてのキーワード引数がサポートされています（実際には意図されている可能性があります）。

しかし、これはとにかく私の印象です。 mul!(C, A, B, α, β)はmul!(C, A, B)同じくらい公開されていると思いますか？

私たちはお互いを超えて話していると思います。 私が言っているのは、私は（まだ）別の機能を導入する価値があるとは思わないということです。 したがって、私の前のコメントへの私の参照。 これは、5つの引数mul!の非推奨に関する説明とは別のものです。

ただし、別の関数を追加することにした場合は、5つの引数mul!を単に壊すのではなく、非推奨にするのが最善だと思います。 もちろん、3つの引数mul!ほど一般的には使用されていませんが、単に壊すのではなく、非推奨にしないのはなぜですか？

これは、5つの引数mul!の非推奨に関する説明とは別のものです。

コメントの最後の段落https://github.com/JuliaLang/julia/issues/23919#issuecomment-430952179の私の解釈は、@ simonbyrneがでした。 / 23919＃issuecomment -430809383は、新しい5つの引数関数ですが、_public API_を維持する場合に比べて価値が低いと考えられています（「名前の変更」と「非推奨」についてお話しました）。 そのため、5つの引数mul!が公開されているかどうかを検討することが重要だと思いました。

しかし、あなたはまた、あなたが今言及しているものであると私が思う「余分な機能」を持つことの正当化についても言及しました。 計算_C = AB_と_C =αAB+βC_は十分に類似しているので、同じ名前で両方を説明できると主張していますか？ 3つの引数mul!を一般化する他の方法がある可能性があるため、私は実際には同意しません。たとえば、_y =A₁A₂⋯Aₙx_https ：//github.com/JuliaLang/juliaのmul!(y, A₁, A₂, ..., Aₙ, x) / issues / 23919＃issuecomment -402953987？

単に壊すのではなく、非推奨にしてみませんか？

前のコメントで述べたように、5つの引数mul!非推奨にすることは、別の関数を導入する場合に行うべき正しいことであることに同意します。 このコードは私のPR＃29634にすでに存在します。

C = ABとC =αAB+βCの計算は十分に類似しているので、同じ名前で両方を説明できると主張していますか？

はい、前者はβ=0の後者であるためです。 muladd! / addmul!はC = αAB + βCより正確な名前であると主張するのは公正ですが、そこに到達するには、別の行列乗算関数（ muladd! / addmul! ）またはmul!名前を変更すると、今は価値がないと思います。 もしこれが春に起こっていたら、変更を検討するのは簡単だったでしょう。

3つの引数のmulを一般化する他の方法がある可能性があるので、私は実際には同意しません！：

ジュリアはたまたまαとβ引数なしでインプレース行列乗算メソッドを定義しましたが、行列乗算の伝統は実際にはBLAS-3に基づいており、一般的な行列乗算関数はC = αAB + βC 。

mul!名前を変更

stdlibまたはダウンストリームユーザーモジュール/コードで名前を変更することを意味しますか？ 前者の場合は、＃29634で（LinearAlgebraとSparseArraysの場合）すでに実行されているので、心配する必要はないと思います。 後者を意味するなら、私はそれが再び公の議論に帰着すると思います。

行列乗算の伝統は、実際にはBLAS-3に基づいています

しかし、ジュリアはすでにBLASの命名規則から逸脱しています。 それで、もっとわかりやすい名前を付けるのはいいことではないでしょうか？

stdlibまたはダウンストリームユーザーモジュール/コードで名前を変更することを意味しますか？

29634はmul!関数の名前を変更しません。 新しい関数addmul!追加されます。

しかし、ジュリアはすでにBLASの命名規則から逸脱しています。

ネーミングについて話しているのではありません。 少なくとも、Fortran 77には、関数名とディスパッチの両方に関してはないいくつかの制限があるため、正確ではありません。 私は何が計算されているかについて話している。 BLAS-3の一般的な行列乗算関数はC = αAB + βCを計算し、Juliaではmul! （fka A_mul_B! ）になっています。

それで、もっとわかりやすい名前を付けるのはいいことではないでしょうか？

そうなるでしょう、そして私はそれを数回言いました。 問題は、基本的に同じことを行う2つの行列乗算関数が必要になるほど良くないことです。

29634はmul!関数の名前を変更しません。 新しい関数addmul!追加されます。

私が言いたかったのは、5つの引数mul!がaddmul!に名前が変更されたことです。

問題は、基本的に同じことを行う2つの行列乗算関数が必要になるほど良くないことです。

基本的に同じかどうかは主観的だと思います。 _C =αAB+βC_と_Y =A₁A₂⋯AₙX_はどちらも_C = AB_の数学的に有効な一般化だと思います。 _C =αAB+βC_が独自の一般化でない限り、議論は十分に強力ではないと思います。 また、BLAS APIを知っているかどうかにもよりますが、それが一般的なJuliaユーザーの基本的な知識であるかどうかはわかりません。

また、_C = AB_と_C =αAB+βC_は、 Cが使用されるかどうかという点で、計算上非常に異なります。 前者の場合は出力専用パラメータ、後者の場合は入出力パラメータです。 この違いは視覚的な手がかりに値すると思います。 mul!(some_func(...), ...) 、 mul!が5つの引数形式である場合、引数の数を数える必要があります（括弧を一致させる必要があるため、関数呼び出しの結果である場合は困難です）。 some_funcが何らかの計算を行うのか、それとも単なる割り当てを行うのかを確認します。 addmul!場合、 mul!(some_func(...), ...) some_funcは割り当てのみを行うとすぐに予想できます。

基本的に同じかどうかは主観的だと思います。 C =αAB+βCとY =A₁A₂⋯AₙXはどちらもC = ABの数学的に有効な一般化だと思います。 C =αAB+βCが独自の一般化でない限り、議論は十分に強力ではないと思います。

これは一意の一般化ではないかもしれませんが、ほぼ同じコストで計算できる一般化であり、他の線形代数アルゴリズムを構築するための有用なプリミティブを形成します。 多くの場合、さまざまな線形代数関連のアルゴリズムを実装するときにゼロ以外のベータ値が必要であり、常にBLAS.gemm!にフォールバックする必要がありました。 あなたが言及したような他の一般化は、とにかく中間の一時的なものなしでは一発で計算することができないので、インプレースバージョンははるかに有用ではありません。 さらに、それらは基本的な操作ほど一般的には有用ではありません。

また、BLAS APIを知っているかどうかにもよりますが、それが一般的なJuliaユーザーの基本的な知識であるかどうかはわかりません。

デフォルトの引数α=1とβ=0がまだ存在している限り、3つの引数mul!は、BLASのバックグラウンドがなくてもJuliaユーザーが合理的に期待することを実行します。 より高度なオプションについては、任意の言語と機能を使用する必要があるため、マニュアルを参照する必要があります。 さらに、この1回のmul!呼び出しは、 gemmだけでなく、 gemvとtrmv （奇妙なことにαとBLAS APIのβパラメータ）およびおそらく他の多くのパラメータ。

私は、BLAS-3が計算の観点から正しい一般化であり、非常にうまく構成されていることに同意します。 同じ名前を使用することを正当化するのは「十分にユニーク」ではないと思うという理由だけで、別の可能な一般化を提起しています。 https://github.com/JuliaLang/julia/issues/23919#issuecomment-442167056の最後の段落にあるoutput-onlyとinput-outputの引数も参照してください。 名前が違うとコードの読み取り/レビューが簡単になると思います。

さらに、この単一のmul!呼び出しは、 gemmだけでなく、 gemvとtrmv （奇妙なことにαとBLAS APIのβパラメータ）およびおそらく他の多くのパラメータ。

はい、すでに＃29634で実装されており、名前が決まったら（そしてレビューを受けて）準備ができています！

私はこの会話をフォローするのに苦労しています（少し長くて広大です...ごめんなさい！）、主要な提案はmul!(C, A, B; α=true, β=false)ようなものですか？

αとβのキーワード引数はテーブルにないと思います。 たとえば、 @ andreasnoackは、 https： //github.com/JuliaLang/julia/issues/23919#issuecomment-365762889でキーワード引数を却下しました。 @simonbyrneはhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-426881998でキーワード引数について言及しましたが、彼の最新の提案https://github.com/JuliaLang/julia/issues/23919#issuecomment-431046516は定位置です引数。

名前はまだ決まっていません（つまり、 mul! vs addmul! vs muladd! ）。それが中心的なトピックだと思います（または少なくともそれが私の願いです）。

通常、この種の論争をどのように解決しますか？ 投票？ トリアージ？

主要な提案はmul！（C、A、B;α= true、β= false）のようなものですか？

私はこれが好きですが、クワーグはありません。

キーワードの事を見ませんでした。 また、Unicodeキーワードを追加することも躊躇しています。 これらのデフォルト値を使用した位置引数は問題ないと思います。 次の投票に関しては、私のものは普通のmul!です。 これはmul!一般化であり、新しい名前を必要としないほど具体的で便利だと思います。

（少なくとも現時点では）データを収集するために、投票を行いましょう。

_C =αAB+βC_のお気に入りの関数名は何ですか？

• ：+1： mul!
• ：-1： addmul!
• ：smile： muladd!
• ：tada：何か他のもの

私には、 addmul!はAB + Cではなく(A+B)Cを説明しているようです。

最初はmul!に投票し、次に操作を見て、「乗算してから加算するので、明らかにmuladd!と呼ぶ必要があります。今では呼び出すことは考えられません。それがインプレースであるという事実は、 !によって明確に示され、スケーリング部分はキーワード引数に適しているようです。

乗算してから加算するので、明らかにmuladd!と呼ぶ必要があります。

デフォルト値β=trueを使用する場合のみですが、他の値の場合は、さらに一般的なものになります。 それでは、それをmul!と呼ばないことのポイントは何ですか？デフォルト値β=false以外の値も、より一般的なものを提供します。 そして、 muladd(x,y,z) = x*y + zと比較して、引数をどのように並べますか？ やや混乱するでしょうね？

muladd!は、そうでない場合に説明的に聞こえるという欠点があると思います。名前が付けられた説明は、スケーリング部分について言及するとscalemuladd!ようになります。

ですから、私はmul!を好みます。それは、期待につながらないほど説明がないからです。

そうは言っても、私はLazyArrays.jl MulAddレイジーバージョンを呼び出します。

C （ mul! ）の値を使用しない関数と、それを使用する関数を区別するのは良いことなので、 mul!よりもmuladd!方が好きです。 （ muladd! ）。

• 技術的には、行列の乗算です：[AC] * [Bα; Iβ]または、以下のコメントを参照してください、[αAβC] * [B; 私]
• 〜スパース行列にはすでに5引数のmul!があり、密行列の場合も同じです〜（新しい引数ではありません）

だから私はそれをmul!と呼ぶことに賛成だろう。

• 技術的には、行列の乗算です：[AC] * [Bα; Iβ]

... eltypeに可換乗算がある場合

... eltypeが可換である場合。

IIRC @andreasnoackジュリアとの議論からわずか定義gemm / gemvとy <- A * x * α + y * βそれが最も理にかなっているため。

@haampieそれはよく知っています！ ＃29634で逆に実装しました。

これは限られた助けですが、

       C = α*A*B + β*C

これは、操作を表現するために思いつくことができる最善の方法です。したがって、マクロ<strong i="8">@call</strong> C = α*A*B + β*Cまたは<strong i="10">@call_specialized</strong> ...など、これらの線に沿ったものが自然なインターフェイスになります。これも同様の状況です。 次に、基になる関数を何でも呼び出すことができます。

@dlfivefiftyによる@ mschauerLazyArrays.jlには、構文のように5つの引数mul!を呼び出すための優れた構文があります（その他！）。

最初に関数ベースのAPIを確立し、パッケージの作成者が特殊なマトリックスのためにAPIのオーバーロードを開始できるようにする必要があると思います。 その後、ジュリアコミュニティはそれを呼び出すための砂糖の実験を開始できます。

デフォルト値β=trueを使用する場合のみですが、他の値の場合は、さらに一般的なものになります。 では、それをmul!と呼ばないことのポイントは何ですか？デフォルト値β=false以外の値も、より一般的なものを提供します。 そして、 muladd(x,y,z) = x*y + zと比較して、引数をどのように並べますか？ やや混乱するでしょうね？

確かにそこにはある程度のスケーリングがありますが、操作の「骨」は明らかに乗算と加算です。 muladd署名に一致するmuladd!(A, B, C, α=true, β=false)でも問題ありません。 もちろん、文書化する必要がありますが、それは言うまでもありません。 muladdが最初に添加剤の部分を取りたいと思うのですが、船はその部分で航海しました。

そして、 muladd(x,y,z) = x*y + zと比較して、引数をどのように並べますか？ やや混乱するでしょうね？

これが、私がmuladd!よりもaddmul!を好む理由です。 引数の順序がスカラーmuladdとは関係がないことを確認できます。 （私はmul!よりもmuladd!方が好きですが）

ここでのFWIWは、これまでの議論の要約です。 （私は中立を目指しましたが、私はプロmuladd! / addmul!なので、それを覚えておいてください...）

主な不一致は、_C = AB_と_C =αAB+βC_が後者に新しい名前を付けるのに十分異なるかどうかです。

彼らは十分に似ているので...

1. それはBLAS-3であり、うまく構成可能です。 したがって、_C =αAB+βC_は_C = AB_の明らかな一般化です（https://github.com/JuliaLang/julia/issues/23919#issuecomment-441246606、https://github.com/JuliaLang/julia/issues/ 23919＃issuecomment-441312375など）

2. _ " muladd!は、そうでない場合に説明的に聞こえるという欠点があります。説明的な名前は、スケーリング部分について言及するとscalemuladd!ようになります。" _ --- https://github.com/ JuliaLang / julia / issues / 23919＃issuecomment -441819470

3. _ "技術的には行列の乗算です：[AC] * [Bα;Iβ]" _ --- https://github.com/JuliaLang/julia/issues/23919#issuecomment -441825009

彼らは十分に異なっているので...

1. _C =αAB+βC_は乗算以上です（https://github.com/JuliaLang/julia/issues/23919#issuecomment-430809383、https://github.com/JuliaLang/julia/issues/23919#issuecomment-427075792、 https://github.com/JuliaLang/julia/issues/23919#issuecomment-441813176など）。

2. Y = A₁ A₂ ⋯ Aₙ Xようなmul!他の一般化がある可能性があります（https://github.com/JuliaLang/julia/issues/23919#issuecomment-402953987など）

3. 入出力パラメーター：引数の数に基づいてCのデータを使用する関数があると混乱します（https://github.com/JuliaLang/julia/issues/23919#issuecomment -441267056、https：//github.com/JuliaLang/julia/issues/23919#issuecomment-441824982）

mul!が優れているもう1つの理由は...：

1. スパース行列にはすでにそれがあります。 したがって、下位互換性に適しています。 反論： 5つの引数mul!は文書化されていないため、パブリックAPIと見なす必要はありません。

そして、なぜmuladd! / addmul!が優れているのか...：

1. mul!とmuladd! / addmul!別々に3つまたは4つの引数の「便利な関数」を使用できます（https://github.com/JuliaLang/julia/issues / 23919＃issuecomment-402953987、https：//github.com/JuliaLang/julia/issues/23919#issuecomment-431046516など）。 反論： mul!(y, A, x, 1, 1)書くことは、 mul!(y, A, x) （https://github.com/JuliaLang/julia/issues/23919#issuecomment-430674934など）と比較してそれほど冗長ではありません。

客観的な要約をありがとう@tkf

muladdの署名と一致するようにmuladd！（A、B、C、α= true、β= false）でも問題ありません。

mulladd!という関数の場合、デフォルトがβ=trueになることを願っています。 それでも、 muladdから決定されるこの引数の順序は、 mul!(C,A,B)に関して非常に混乱すると思います。

私は間違っているかもしれませんが、ほとんどの人/アプリケーション/高水準コード（乗算演算子*だけではまだ満足していない）にはmul!が必要だと思います。 βCとβ=1 （ true ）などを混在させる機能は、行列乗算用のBLAS APIが有効であることを知っている人々によって、低レベルのコードで使用されます。この。 これらの人々は、 mul!下でこの機能を探すと思います。これは、 gemm 、 gemv 、...への確立されたJuliaインターフェイスです。新しい名前を追加します（混乱します）反対の引数の順序）は価値がないようです。 私は利益を見ることができませんか？

これらの人々は、 mul!下でこの機能を探すと思います。これは、 gemm 、 gemv 、...への確立されたJuliaインターフェイスです。新しい名前を追加します（混乱します）反対の引数の順序）は価値がないようです。 私は利益を見ることができませんか？

mul! docstringでmuladd!に言及できるので、発見可能性は大きな問題ではないと思います。 BLASを十分に理解している人は、APIを探す場所を知っているでしょう。

位置引数とキーワード引数について：ここではまだ説明していませんが、 α対角行列とするC = αAB + βCは、スカラーαと同じくらい効率的かつ簡単に実装できると思います。 このような拡張では、キーワード引数では不可能なαの型でディスパッチできる必要があります。

また、非可換eltypeの場合、 muladd!(α', B', A', β', C') （仮想引数の順序）を呼び出すことにより、 C = ABα + Cβを効率的に計算することができます。 レイジーラッパーAdjoint(α)およびAdjoint(β)ディスパッチできる必要がある場合があります。 （私はジュリアで非可換数を個人的に使用しないので、これはおそらく非常に仮説的です。）

このmultiply-add関数は、ライブラリ実装者のような熟練したプログラマー向けの低レベルAPIであるという@Juthoの指摘に同意します。 このAPIでは拡張性が優先度が高く、位置的な議論が進むべき道だと思います。

キーワード引数を回避するためのもう1つの引数は、 @ andreasnoackがhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-365762889の前に言ったことです。

αとβの名前も、BLASを知らない限り、あまり直感的ではありません。

実際の使用回数：@tkfは、必ず、私の議論はかなりあるβ != 0のそれよりも小さくなりますβ == 0 、およびそれを必要とする人には、これはもう少し一般的な見つけるために驚かれることはありませんmul!下での動作。 したがって、特に引数の順序がめちゃくちゃになっているので（少なくともmuladd!で）、これを新しい名前で分離することのメリットはわかりません。 それが新しい方法でなければならない場合、私はaddmul!に対するあなたの議論にも共感します。

それを必要とする人は、 mul!下でこの少し一般的な振る舞いを見つけても驚くことはありません。

私はこの点に同意します。

したがって、これを新しい名前で分離することのメリットはわかりません。

何か害が見られない限り、他の人々が利益を見ているので、それは世界的な利益だと思います。

特に引数の順序がめちゃくちゃになっているので（少なくともmuladd!で）

私はあなたがこれを害として数えるだろうと思います、そして私はポイントを得ます。 muladd! / addmul!他のメリットがより重要だと思うだけです。

私はあなたがこれを害として数えるだろうと思います、そして私はポイントを得ます。 muladd！/ addmul！には他にもメリットがあると思います。 より重要です。

これは、 mul!が、αとβへの完全なアクセスを許可しないことによって制限されている場合でも、乗算に関連するいくつかのBLAS操作への単一のエントリポイントであるという事実とともに、確かに害です。 そして今muladd!では、引数によって簡単にキャプチャできる（実際、BLAS APIの引数によってキャプチャされる）要求された操作のわずかな違いに応じて、2つの異なるエントリポイントがあります。 。 そもそも、BLAS APIへのフルアクセスを提供しなかったのはジュリアの間違いだったと思います（@tkfを修正してくれてありがとう）。 それは古い恐ろしいFortran命名規則にもかかわらず、私はこれらの人がなぜ彼らがこのように物事をしているのか知っていたと思います。 しかし、同様に、この操作ファミリー（つまり、αとβによってパラメーター化された2パラメーターの操作ファミリー）は、BLASの場合と同様に、単一のエントリポイントに属していると思います。

私の見解で最も有効な反論は、 Cの元のデータにアクセスするかどうかの違いです。 しかし、ジュリアがゼロの結果を保証する方法としてfalse乗算を採用しているという事実を考えると、他の要素がNaN 、これも処理されると思います。 しかし、おそらくこの事実はよりよく伝達/文書化する必要があり（私が文書を読んでからしばらく経ちました）、私も最近それについて学びました。 （そのため、KrylovKit.jlでは、任意のベクトルのようなユーザータイプをゼロで初期化するために、 fill!メソッドの存在が必要です。しかし、代わりにrmul!(x,false)にすることができることがわかりました。したがって、 fill!が実装されていることを強制する必要はありません）。

muladd！/ addmul！には他にもメリットがあると思います。 より重要です。

では、質問を逆にしましょう。新しい方法を持つことのこれらの他の利点は何ですか？ もう一度要約を読みましたが、コメントしたばかりのCにアクセスするポイントしかわかりません。

私は今朝妻に、手術の命名に関してジュリアコミュニティで2ヶ月の長い会話があったと言いました。 彼女はそれを「フレッド」と呼ぶことを提案した。 -頭字語も深い意味もありません。良い名前です。 彼女に代わってこれを出すだけです。

彼女が感嘆符を付けてくれて良かったです！ 😄

まず、念のため、私の懸念はほとんどコードの可読性にのみ起因し、書き込み可能性や発見可能性には起因しないことを明確にしておきます。 あなたは一度コードを書きますが、何度も読みます。

新しい方法を持つことのこれらの他の利点は何ですか？

あなたがコメントしたように、私は出力対入出力パラメータの引数が最も重要だと思います。 しかし、これが_C =αAB+βC_が_C = AB_と異なると思う理由の1つにすぎません。 また、前者の表現が後者の厳密な「スーパーセット」であるという意味で異なるという単純な事実は、コード内で明確な視覚的表示が必要だと思います。 別の名前は、中級プログラマー（または少し焦点の定まらない上級プログラマー）がコードをスキミングし、 mul!よりも奇妙なものを使用していることに気付くのに役立ちます。

投票をもう一度確認mul!からmuladd!です。 前回見たときはmul!が勝っていました。 彼らが移動する前にここにそれを記録しましょう：笑い：

• mul! ：6
• addmul! ：2
• muladd! ：8
• 他の何か：1

もう少し真剣に、私はまだこのデータがmul!示していないか、 muladd!が他よりも明確であると思います。 （ addmul!が少数派であることを示していますが：sob :)

行き詰まったような気がします。 どうすれば先に進みますか？

代わりにgemm!と呼んでください。

ジェムと呼んでください！ 代わりに？

これが冗談だと​​いいのですが...行列*ベクトルにgemm!(α, A::Matrix, x::Vector, β, y::Vector) = gemv!(α, A, x, β, y)を提案していない限り。

PRをマージして改善し、他のPRにmuladd!を追加するかどうかを心配できるように、今のところ（スパース行列で）すでに存在するmul!インターフェイスを残しておくことができますか？ ？

たぶん、ここの誰にとってもすでに明らかですが、私は投票がそうではないことを強調したかっただけです

• mul! vs muladd!

だが

• mul! vs（ mul!およびmuladd! ）

つまり、1つではなく2つの突然変異乗算関数を持っています。

mul!を支持して投稿したときはいつでも、投票がmul!から（ mul!とmuladd! ）に移動したようだったので、もう投稿しないことにしました。

しかし、私は質問がありますか？ 現在の多数決で、同時にmul!(C,A,B)とmuladd!(A,B,C,α=true,β=true) 、 axpy!とaxpby!を置き換えるPRを準備したい場合よりジュリアンな名前add! 、 add!(y, x, α=true, β=true)またはadd!(x, y, α=true, β=true) （わかりやすくするために、 yは変更されています）。 または、他の何か？

明らかでない場合、 muladd!(A,B,C)は、変更された引数が最初に実行されるという規則に違反します。

すでに存在するmul!インターフェースを残していただけませんか

@jebejこの「下位互換性」の議論は広く議論されていると思います。 それでも、それは誰も納得させません（世論調査を見ると、それは私だけではありません）。

他のPRにmuladd!を追加するかどうか心配ですか？

パブリックAPIを壊すことは悪いことです。 したがって、 mul!と言うと、永久にmul!ます（ただし、理論的には、LinearAlgebraはメジャーバージョンをバンプしてAPIを破壊する可能性があります）。

axpy!とaxpby!をよりジュリアンな名前add!に置き換えるPRを準備したいのですが、それがadd!(y, x, α=true, β=true)またはadd!(x, y, α=true, β=true)

@Juthoありがとう、それは素晴らしいことです！ multiply-add APIの呼び出しシグネチャを決定したら、引数の順序を選択するのは簡単だと思います。

muladd!(A,B,C)は、変更された引数が最初に実行されるという規則に違反します。

@simonbyrneしかし（https://github.com/JuliaLang/julia/issues/23919#issuecomment-426881998ですでに述べたように）、 lmul!とldiv!最初以外の引数を変更します。 したがって、 muladd!(A,B,C,α,β)を選択から除外する必要はなく、この署名のマイナス点として数える必要があると思います。

（ただし、「テキスト注文」APIを使用する場合は、 muladd!(α, A, B, β, C)を使用すると思います。）

ちなみに、投票の結果でわからないのは、 muladd!とaddmul!の非対称性です。 C = βC + αABと書くと、 addmul!方が自然に見えると思います。

@tkfそれはあなたが最初に行う操作についてです。 私にとってaddmul!は、 (A+B)Cように、最初に加算を行ってから乗算することを提案しています。 もちろんそれは主観的です。 しかし、良い名前は直感に訴えるはずです。

ああ、その点はわかります。

これはまだ行き詰まっているので、私の提案では、関数定義で構成される使用パターンがあります（2番目は@callexprになります）

@callexpr(C .= β*C + α*A*B) = implementation(C, β, α, A, B)
@callexpr(C .= β*C + A*B) = implementation(C, β, true, A, B)

そして多分もっとディスパッチしやすいフォーム（2番目は@callnameで行く）

function @callname(β*C + A*B)(C::Number, β::Number, A::Number, B::Number)
     β*C + A*B
end

と呼び出し

@callexpr(A .= 2*C + A*B)
@callexpr(2*3 + 3*2)

また、 callexpr代数演算を一意の関数名にマングルする方法を心配する（または知る）必要はありません（引数記号に依存せず、演算と演算の順序のみに依存します）。
私は実装について少し考えました、そしてそれはうまくいくはずです。

@mschauerそれは興味深い方向だと思います。 新しい号を開くことはできますか？ 提案しているAPIは、他の多くの問題を解決できます。 解決できる問題の単一のインスタンスを解決するよりも、慎重な設計プロセスを経る必要があると思います。

だから、1.1の機能フリーズが来週になるという噂を聞いた。 次のマイナーリリースは「たった」4か月先ですが、1.1でリリースできれば本当に嬉しいです...

とにかく、PRをマージする前に、呼び出しの署名（引数とキーワードの順序かどうか）も決定する必要があります。

それでは、もう一度投票してみましょう（それは素晴らしい刺激物であることがわかったので）。

_C =ABα+Cβ_にmuladd!を使用する場合、お気に入りの通話署名は何ですか？

• ：+1： muladd!(C, A, B, α, β)
• ：-1： muladd!(A, B, C, α, β)
• ：smile： muladd!(C, A, B; α, β) （：+ 1：のようですが、キーワードargumentsbs付き）
• ：tada： muladd!(A, B, C; α, β) （：-1：と同様ですが、キーワード引数付き）
• ：混乱： muladd!(A, B, α, C, β)
• ：heart：何か他のもの

他のキーワード引数名​​を念頭に置いている場合は、 αとβを使用して投票し、どの名前が優れているかについてコメントしてください。

名前を決定していないので、 mul!についても決定する必要があります。

_C =ABα+Cβ_にmul!を使用する場合、お気に入りの通話署名は何ですか？

• ：+1： mul!(C, A, B, α, β)
• ：-1： mul!(A, B, C, α, β)
• ：smile： mul!(C, A, B; α, β) （：+ 1：のようですが、キーワード引数付き）
• ：tada： mul!(A, B, C; α, β) （これは不可能です）
• ：混乱： mul!(A, B, α, C, β)
• ：heart：何か他のもの

注：既存のAPI mul!(C, A, B)は変更していません

注：既存のAPI mul!(C, A, B)は変更しません

私はこの事実に十分な注意を払っていませんでした—私たちはすでにmul!を持っています、そしてこれはそれが意味することです：

mul!(Y, A, B) -> Y

行列-行列または行列-ベクトルの積A*Bを計算し、結果をYに格納して、既存のY値を上書きします。 Yは、 AまたはBいずれかでエイリアス化してはならないことに注意してください。

それを考えると、次のように拡張するのは非常に自然なことのようです。

mul!(Y, A, B) -> Y
mul!(Y, A, B, α) -> Y
mul!(Y, A, B, α, β) -> Y

行列-行列または行列-ベクトル積A*Bを計算し、結果をYに格納して、既存のY値を上書きします。 Yは、 AまたはBいずれかでエイリアス化してはならないことに注意してください。 スカラー値αが指定されている場合、 A*B代わりにα*A*Bが計算されます。 スカラー値βが指定されている場合、代わりにα*A*B + β*Yが計算されます。 同じエイリアシング制限がこれらのバリアントに適用されます。

ただし、これには大きな懸念があると思います。少なくともmul!(Y, A, B, C, D)がA*B*C*DをYに計算するのA*B*C*D自然なことのようですが、その一般的な概念は非常にひどく衝突しますmul!(Y, A, B, α, β)コンピューティングα*A*B + β*C 。 さらに、 A*B*C*DをY計算することは、中間の割り当てを避けて効率的に実行することが有用で可能であると思われるので、その意味をブロックしたくありません。 。

mul!他の自然な一般化を念頭に置いて、ここに別の考えがあります：

mul!(Y, α, A, B) # Y .= α*A*B

これは、 args掛け合わせて、 outを計算して書き込む、 mul!(out, args...)の一般的なモデルに適合します。 αが特別な場合ではなく、スカラーであることに対処するためにディスパッチに依存しています。これは、乗算しているもう1つのことです。 αがスカラーで、 A 、 B 、 Yが行列の場合、これを非常に効率的に行うためにBLASにディスパッチできます。 それ以外の場合は、一般的な実装を行うことができます。

さらに、非可換フィールド（クォータニオンなど）を使用している場合は、 αによるスケーリングがどちら側で発生するかを制御できます。 mul!(Y, A, B, α)はαでスケーリングします。左ではなく右：

mul!(Y, A, B, α) # Y .= A*B*α

はい、クォータニオンに対してBLASを呼び出すことはできませんが、それは一般的であり、おそらくそれでもかなり効率的に行うことができます（おそらく、何らかの方法でBLAS呼び出しに変換することさえできます）。

Y .= α*A*Bに対するそのアプローチを想定すると、次の質問は次のようになります。 Yスケーリングとインクリメント

mul!((β, Y), α, A, B) # Y .= β*Y .+ α*A*B

少し奇妙ですが、動作します。 また、非可換フィールドでは、次のように、右側のYにβを掛けるように依頼できます。

mul!((Y, β), α, A, B) # Y .= Y*β .+ α*A*B

非可換分野での完全な一般性では、次のように左右両方でスケーリングできます。

mul!((β₁, Y, β₂), α₁, A, B, α₂) # Y .= β₁*Y*β₂ + α₁*A*B*α₂

もちろん、これは少し奇妙で、これに対するBLAS操作はありませんが、GEMMの一般化であり、多くのことを表現でき、厄介なif / elseを実行することなくBLAS操作に簡単にディスパッチできます。ブランチ。

基になるAPI呼び出しとして@StefanKarpinskiの提案が本当に好き

@affine! Y = β₁*Y*β₂ + α₁*A*B*α₂

基礎となる関数は、 @ StefanKarpinskiが提案するようなものになります。

しかし、ここでさらに進む必要があります。 そのためのAPIとジェネリック関数を作成すれば、誰かがそれを効率的に実行するJuliaライブラリを作成すると本当に思います。したがって、ここでBLASに固執するべきではないことに同意します。 MatrixChainMultiply.jlのようなものは、すでに複数の行列計算用のDSLを構築しており、DiffEqはアフィン演算子式を使用して独自のことを行っています。 Baseにアフィン式の表現が1つしかない場合は、すべての作業を同じものに定義できます。

@dlfivefiftyは以前に怠惰な線形代数を調べましたが、それは本当にここで復活する必要があると思います。 ブロードキャストの遅延表現を構築することは、要素ごとの操作を抽象配列および代替の計算ハードウェアで機能させるために重要でした。 線形代数にも同じことが必要です。 線形代数式の表現により、Julia BLASからその場で新しいBLASカーネルを定義したり、方程式をGPU / TPUに転送したりできます。

本質的に、科学計算におけるすべての計算は、要素ごとの線形代数演算に要約されるため、両方の高レベルの記述を持つことは、メタプログラミングして新しい設計を探索するためのツールを構築するのに役立つようです。

この提案についてもっと考える必要がありますが、今のところ、一時的なものなしでA*B*Cを計算したくないと思うとコメントします。 一時的なものを避けるために、多くの算術演算で支払う必要があるように私には思えます。

一時的なものなしでA*B*Cを計算したいとは思わない。

ただし、 mul!場合、すでに出力配列があります。 それが役立つかどうかはわかりません。 いずれにせよ、それは実装の詳細のようです。 API mul!(Y, A, B, C...)は、計算したいものを表現し、実装がそれを行うための最良の方法を選択できるようにします。これがここでの一般的な目標でした。

基になるAPI呼び出しとして@StefanKarpinskiの提案が本当に好き

@ChrisRackauckas ：怠惰、必要な計算を記述し、ある種の最適化パスに、最適化の方法を知っている特定の代数パターンに一致する部分を選択させるなど、外部パッケージで調査できることと調査する必要があることを考えます。このようにmul!を使用することは、このレベルで必要な、一般的でありながら理解しやすい操作のように思えます。

mul!(Y, α, A, B)については、実際の議論はないことに注意してください。他に何を意味するので、 Y .= α*A*B意味する必要があります。 したがって、私にとってここでの唯一の未解決の質問は、行列と左および/または右のスカラーを持つタプルを使用することが、出力配列をインクリメントおよびスケーリングすることを表現するための合理的な方法であるかどうかです。 一般的なケースは次のとおりです。

1. mul!(Y::Matrx, args...) ： Y .= *(args...)
2. mul!((β, Y)::{Number, Matrix}, args...) ： Y .= β*Y + *(args...)
3. mul!((Y, β)::{Matrix, Number}, args...) ： Y .= Y*β + *(args...)
4. mul!((β₁, Y, β₂)::{Number, Matrix, Number}, args...) ： Y .= β₁*Y*β₂ + *(args...)

最初の引数には他に何も許可されません。 これは、オプションでスケーリングと組み合わせて、出力配列に上書きまたは累積することが理にかなっている他の操作のより一般的な規則として採用できます。

mul!(out, args...)とGEMMのようなインターフェースを「マージ」することは私には思い浮かびません

しかし、私の心配は、オーバーロードインターフェイスとして使いやすいかどうかです。 ネストされたタプルに対して適切に機能するには、型システムに依存する必要があります。 ネストされたタプルは、Juliaの型システムのフラットタプルと同じように機能しますか？ 「 Tuple{Tuple{A1,B1},C1,D1} Tuple{A1,B1,C1,D1}がTuple{A2,B2,C2,D2}よりも具体的である場合、 Tuple{Tuple{A1,B1},C1,D1}はTuple{Tuple{A2,B2},C2,D2}よりも具体的である」のようなものが当てはまるのではないかと思います。 そうしないと、オーバーロードAPIとして使用するのが難しいでしょう。

複素行列の再解釈ハックを使用するには、スカラー型をディスパッチする必要があることに注意してください（これはPR＃29634からのものなので、関数名に注意を払わないでください）。

https://github.com/JuliaLang/julia/blob/fae1a7a3ae646c7ea1c08​​982976b57096fb0ae8d/stdlib/LinearAlgebra/src/matmul.jl#L157 -L169

もう1つの懸念は、これが計算グラフエグゼキュータのインターフェイスに多少制限があることです。 multiply-addインターフェースの主な目的は、ライブラリの実装者が効率的に実装できる小さな再利用可能な計算カーネルを定義できるようにするオーバーロードAPIを提供することだと思います。 これは、_C =ABα_のみを実装でき、たとえば_αAB_は実装できないことを意味します（https://github.com/JuliaLang/julia/pull/29634#issuecomment-443103667を参照）。 非可換eltypeに対して_α₁ABα₂_をサポートするには、一時配列または算術演算の数を増やす必要があります。 1人のユーザーがどちらを望んでいるかは明確ではなく、理想的にはこれを構成可能にする必要があります。 この時点で、実行メカニズムから分離された計算グラフ表現が必要です。 これは、外部パッケージ（LazyArrays.jl、MappedArrays.jlなど）で調べる方がよいと思います。 ただし、ある時点でほとんどのユースケースをカバーする実装戦略を見つけることができれば、メインのエントリポイントとしてmul!を使用することは理にかなっています。 これが実際にmuladd!を支持するもう1つの理由だと思います。 将来の呼び出しAPI用にスペースを割り当てます。

私はこの提案についてもっと考える必要があるだろうけど、今のところ、私はちょうど私があなたが一時的になしA B Cを計算したいとは思わないことをコメントします。 一時的なものを避けるために、多くの算術演算で支払う必要があるように私には思えます。

確かに、任意の数のテンソルの収縮を証明できます。全体を評価する最も効率的な方法は、常にペアワイズ収縮を使用することです。 したがって、いくつかの行列を乗算することは、その特殊なケースにすぎません。ペアごとに乗算する必要があります（もちろん、最良の順序は重要な問題です）。 そのため、 mul!(Y,X1,X2,X3...)はそれほど有用なプリミティブではないと思います。 そして最終的には、それがmul!だと私は思います。これは、開発者が特定のタイプに対してオーバーロードできる基本的な操作です。 次に、マクロを使用するなど、より高レベルの構造を使用して、より複雑な操作を記述できます。たとえば、計算グラフを作成します。これは、最終的にmul!などのプリミティブ操作を呼び出すことによって評価されます。 もちろん、そのプリミティブは、 @ StefanKarpinskiが言及している非可換のようなケースを含めるのに十分一般的である可能性があります。

行列の乗算/テンソルの縮約が含まれない限り、プリミティブ演算の観点から考えることはそれほど有用ではなく、放送のようにすべてを融合することが有益である可能性があることは事実です。

一般に、Baseにデフォルトの遅延表現/計算グラフタイプがあるとよいことに同意しますが、 mul!がそれを構築する方法ではないと思います。

@tkf ：

しかし、私の心配は、オーバーロードインターフェイスとして使いやすいかどうかです。 ネストされたタプルに対して適切に機能するには、型システムに依存する必要があります。 ネストされたタプルは、Juliaの型システムのフラットタプルと同じように機能しますか？

はい、私たちは皆その面で良いです。 ネストがどこに入るのかはわかりませんが、タプルでいくつかのものを渡すことは、すべてを即時引数として渡すのと同じくらい効率的です。まったく同じ方法で実装されます。

これは、_C =ABα_のみを実装でき、たとえば_αAB_は実装できないことを意味します。

私は混乱しています...あなたはmul!(C, A, B, α)とmul!(C, α, A, B)を書くことができます。 mul!(C, α₁, A, α₂, B, α₃)書くこともできます。 これは、これまでに提案された中で最も柔軟な汎用行列乗算APIのようです。

もう1つの懸念は、これが計算グラフエグゼキュータのインターフェイスに多少制限があることです。 multiply-addインターフェースの主な目的は、ライブラリの実装者が効率的に実装できる小さな再利用可能な計算カーネルを定義できるようにするオーバーロードAPIを提供することだと思います。

この時点で、実行メカニズムから分離された計算グラフ表現が必要です。

それは事実かもしれませんが、これはそのための場所ではありません。外部パッケージで開発することができ、開発する必要があります。 この特定の問題を解決するために必要なのは、BLAS操作にディスパッチできるものを一般化する行列乗算APIだけです。これは、これが行うこととほぼ同じです。

@Jutho

したがって、いくつかの行列を乗算することは、その特殊なケースにすぎません。ペアごとに乗算する必要があります（もちろん、最良の順序は重要な問題です）。 そのため、 mul!(Y,X1,X2,X3...)はそれほど有用なプリミティブではないと思います。

mul!演算を使用すると、実装で乗算の順序を選択できます。これは便利なプロパティです。 実際、それを実行できる可能性があるため、 *操作を最初にn項として解析しました。同じ理由が、 mul!を使用している場合は、さらに当てはまります。 、おそらくパフォーマンスに十分気を配っています。

一般的に、 mul!提案に賛成か反対かはわかりません。

ネストがどこに来るのかわかりませんが、タプルでいくつかのものを渡すことは、それらすべてを即時の引数として渡すのと同じくらい効率的です

現在のLinearAlgebraでさえやや壊れやすいので、効率については心配していませんでしたが、ディスパッチとメソッドのあいまいさを心配していました（これは、型システムについての理解が不足しているためかもしれません。時々驚かされます）。 メソッドの解決はすべての位置引数のタプルタイプを交差させることによって行われると思ったので、ネストされたタプルについて言及していました。 それはあなたに平らなタプルを与えます。 最初の引数でタプルを使用する場合、ネストされたタプルがあります。

これは、_C =ABα_のみを実装でき、たとえば_αAB_は実装できないことを意味します。

私は混乱しています...あなたはmul!(C, A, B, α)とmul!(C, α, A, B)を書くことができます。

「_C =ABα_は_C = AB_と、_αAB_のような他の候補は行列タイプのすべての組み合わせで効率的に実装できるわけではありません」と言いたいのです。 （効率とは、O時間の複雑さが大きいことを意味します。）これが実際に当てはまるかどうかは定かではありませんが、少なくともスパース行列の場合、他の2つのオプションはありません。

この時点で、実行メカニズムから分離された計算グラフ表現が必要です。

それは事実かもしれませんが、これはそのための場所ではありません。外部パッケージで開発することができ、開発する必要があります。

それがまさに私のポイントです。 このAPIを、そのような使用法の最小限の構成要素と見なすことをお勧めします（もちろん、それがすべての目的ではありません）。 vararg mul!実装と設計は、人々が外部パッケージの設計空間を調査した後に行うことができます。

現在のmul!でさえ、型のディスパッチはすでに「壊れています」。 SubArrayやAdjointなどの構成可能な配列型を操作するために必要なあいまいさのオーバーライドの組み合わせが増えています。

解決策は特性を使用することであり、LazyArrays.jlには特性を備えたmul!の概念実証バージョンがあります。

しかし、これはAPIというよりも実装に関する議論です。 しかし、タプルを使用して用語をグループ化するのは間違っていると感じます。これは、型システムの目的ではありませんか？ その場合、LazyArrays.jlソリューションに到達します。

マル！ 操作により、実装は乗算の順序を選択できます。これは便利なプロパティです。 確かに、それを実行できる可能性があるため、最初に*操作をn項として解析し、同じ理由がmulにも当てはまります。 それを使用している場合は、おそらくパフォーマンスに十分気を配っているので。

*がn aryとして解析されることは非常に便利です。 TensorOperations.jlでこれを使用して、 @tensoroptマクロを実装します。これにより、実際に収縮順序が最適化されます。 n aryバージョンのmul!有用性が低いと思うのは、効率の観点から、結果を配置するための事前に割り当てられた場所を提供することにほとんど意味がないためです。配列は関数内で割り当ててからgcする必要があります。 実際、TensorOperations.jlでは、大規模な一時的な割り当てが、Juliaのgcのパフォーマンスが非常に悪い場所の1つであることに気付いた人が何人かいます（gc時間が50％になることがよくあります）。

したがって、私が正しく理解していれば、 @ tkfによっても提唱されてmul!を真にプリミティブな演算に制限します。2つの行列を3番目の行列に乗算し、場合によってはスカラー係数を使用します。 はい、非可換代数に対してこれを行う最も一般的な方法を考えることができますが、今のところ、当面の必要性は、ジュリアのmul! BLAS（gemm、gemv、...）によって提供される機能への便利なアクセスであると思います。

タプルを使用した提案は嫌いではありませんが、混乱が生じる可能性があります。
ケース4からケース2/3に制限すると、デフォルト値β₁ = 1とβ₂ = 1 （または実際にはtrue ）を意味するようです。 しかし、どちらも指定されていない場合は、突然β₁ = β₂ = 0 （ false ）を意味します。 確かに、 mul!((Y,), args...)ではなくmul!(Y, args...)と書くので、構文は少し異なります。 結局、それはドキュメントの問題なので、私はこれを指摘したかっただけです。

要約すると、私はこの構文に実際に反対しているわけではありませんが、これは導入されている新しいタイプのパラダイムであり、おそらく他の場所でも従う必要があります。 私が反対しているのは、これを任意の数の行列の乗算に一般化したいということです。これは、上で論じたように、の利点がわかりません。

@dlfivefifty ：しかし、これはAPIというよりも実装に関する議論です。 しかし、タプルを使用して用語をグループ化するのは間違っていると感じます。これは、型システムの目的ではありませんか？ その場合、LazyArrays.jlソリューションに到達します。

ただし、ここでは完全なレイジー配列を使用するつもりはありません。そのためのLazyArrayはすでに存在します。 一方、スケーリングYを表現する方法が必要です。 タプルを使用することは、その少量の構造を表現するための単純で軽量なアプローチのように思えます。 他に何か提案はありますか？ β₁とβ₂にlscaleやrscaleキーワードを設定することもできますが、それ以上のエレガントさは感じられず、それをディスパッチします。これは重要ではありませんが、持っておくと便利です。

@Jutho ：したがって、私が正しく理解していれば、 @ tkfによっても提唱されてmul!を真にプリミティブな演算に制限します。2つの行列を3番目の行列に乗算し、おそらくスカラー係数を使用します。 はい、非可換代数に対してこれを行う最も一般的な方法を考えることができますが、今のところ、当面の必要性は、ジュリアのmul! BLAS（gemm、gemv、...）によって提供される機能への便利なアクセスであると思います。

mul!の操作の小さなサブセット、おそらく有効なBLAS呼び出しに構造的に対応するものだけを定義するだけで問題ありません。 それは次のようになります。

# gemm: alpha = 1.0, beta = 0.0
mul!(Y::Matrix, A::Matrix, B::Matrix) # gemm! Y, A

# gemm: alpha = α, beta = 0.0 (these all do the same thing for BLAS types)
mul!(Y::Matrix, α::Number, A::Matrix, B::Matrix)
mul!(Y::Matrix, A::Matrix, α::Number, B::Matrix)
mul!(Y::Matrix, A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β (these all do the same thing for BLAS types)
mul!((β::Number, Y::Matrix), α::Number, A::Matrix, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, α::Number, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, B::Matrix, α::Number)
mul!((Y::Matrix, β::Number), α::Number, A::Matrix, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, α::Number, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β₁*β₂ (these all do the same thing for BLAS types)
mul!((β₁::Number, Y::Matrix, β₂::Number), α::Number, A::Matrix, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, α::Number, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, B::Matrix, α::Number)

何のために？ なぜBLAS操作の表現方法にそれほど多くのバリエーションを許可するのですか？

1. それは人々が彼らの意図を表現することを可能にするので—意図が左または右または両方で乗算することであるならば、なぜ人々がそれを表現して正しい実装を選択することを許可しませんか？

2. 非可換要素タイプに対しても正しいことを行う一般的なフォールバックを持つことができます。

この問題の要点は、gemmを含むインプレース行列乗算を一般化することです。 gemmよりも一般的です！。 それ以外の場合は、 gemm!を書き続けてみませんか？

ただし、ここでは完全なレイジー配列を使用するつもりはありません。

「完全なレイジー配列」と言っているのではなく、コンパイル時に最終的に削除されるBroadcastedと同じ意味でレイジーを提案しています。 基本的に、関数の怠惰なアプリケーションを表すためにAppliedを追加し、タプル（コンテキストを含まない）を使用する代わりに、次のようなものを作成します。

materialize!(applied(+, applied(*, α, A, B), applied(*, β, C)))

これは、放送の.*表記のように砂糖でコーティングして読みやすくすることができますが、タプルベースの提案とは異なり、これは何が必要かをすぐに明確にすると思います。

@StefanKarpinskiは、前に述べたように、

mul!((β₁::Number, Y::Matrix, β₂::Number), α₁::Number, A::Matrix, α₂::Number, B::Matrix, α₃::Number)

そして、そのすべての縮小バージョン、つまり、5つのスカラー引数のすべてが存在しない可能性がある場合、それは2 ^ 5 = 32の異なる可能性です。 そして、これはさまざまな行列またはベクトルのすべての可能性と組み合わされます。

放送のようなアプローチがより実現可能であるという@dlfivefiftyに同意します。

はい、私はいくつかのオプションを省略していることに気づきましたが、32のメソッドは私にはそれほどクレイジーではないようです。結局、それらを手で書く必要はありません。 materialize!(applied(+, applied(*, α, A, B), applied(*, β, C)))記述できる「ブロードキャストのようなシステム」または遅延評価システムを追加することは、はるかに大きな追加であり、この問題の範囲外のgemm!直接電話をかけ続けることを許可する傾向があります。

はい、それはおそらく本当です。 デフォルトを簡単に提供するために、スカラー引数を後ろに置く方が簡単だと思いました。 しかし、いくつかの@evalメタプログラミングを使用して、32の定義すべてを簡単に生成できる場合、それは同様に優れています。 （ご存知のとおり、 mulはgemm!だけでなく、 gemvとtrmmなどにもなります）。

それは単なるBLASラッパーではないことを付け加えておきます。 stdlibには、他にも純粋なJuliaに特化したメソッドがあります。 また、これをオーバーロードAPIとして使用することも重要です。パッケージの作成者は、特別な行列タイプに対してmul!を定義できます。

これが私のスタンスだと思います。

1. mul!(C, A, B, a, b)はすでにSparseArrays.jlに存在するため、今すぐサポートすることもできます。
2. マトリックスタイプでのディスパッチは適切にスケーリングされないため、他に何もするべきではありません。 （BandedMatrices.jl、BlockArrays.jl、LowRankApprox.jlなどのメンテナーとして。経験からそれを述べることができます。）
3. 特性ベースの設計は適切に拡張できますが、設計パターンがすでに確立されているため、オールインしてAppliedようなブロードキャストを行うのが最善です。 これはJulia2.0まで待たなければならず、私のニーズに合ったプロトタイプがLazyArrays.jlで開発され続けています。

あなたがの曖昧さ回避の難しさだと思いますか@dlfivefifty mul!((Y, β), α, A, B) APIは、のように等しく、 mul!(Y, A, B, α, β) ？ Transposeなどのマトリックスラッパーを考慮すると、難易度が高くなります

1. mul!(C, A, B, a, b)はすでにSparseArrays.jlに存在するため、今すぐサポートすることもできます。

誰かがmul!(C, A, B, a, b)がC .= b*C + a*A*Bを意味することを完全に考えずに決定したという事実は、これを倍増する正当な理由ではないことを強調します。 mul!が*インプレースバージョンである場合、 mul!(out, args...)がout .= *(args...)以外の意味をどのように意味するのかわかりません。 率直に言って、これは、歴史的な偶然によってのみ存在する、よく考えられていない、一貫性のないAPIの混乱であるシステムになってしまう方法です。 mul!関数はSparseArraysからエクスポートされておらず、その特定のメソッドは文書化されていないため、これは、関数がなかったために追加されたと思われる、思いがけないメソッドを定着させる最も簡単な理由です。公開していません！ その間違いを元に戻し、代わりにmul!メソッドを削除/名前変更することを提案します。

この議論の残りの部分から、すべての利害関係者が標準ライブラリの外で特性や怠惰でもっと凝ったことをしたいので、他に何もすべきではないように思えます。 物を削除するのはいつでもいいので、私はそれで大丈夫です。

この議論の残りの部分から、すべての利害関係者が標準ライブラリの外で特性や怠惰でもっと凝ったことをしたいので、他に何もすべきではないように思えます。 物を削除するのはいつでもいいので、私はそれで大丈夫です。

あなたは少しうんざりしているようです、それは理解できます。 しかし、結論は真実ではないと思います。 現在の提案がスケーラブルな方法で実装でき、パッケージ開発者が独自のマトリックスおよびベクトルタイプ（@tkfで言及）の定義をオーバーロードするのに便利であると確信している場合、それは素晴らしい方法です。フォワード。

特に、パッケージ開発者は以下を実装するだけでよいと思います。

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

そして多分、例えば、

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::Adjoint{<:MyMat}, α₂, B:: MyVecOrMat, α₃)
...

Julia Base（というより、LinearAlgebra標準ライブラリ）がすべてのデフォルト値などを処理します。

パッケージ開発者は以下を実装するだけでよいと思います。

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

文書化することをお勧めします

mul!((Y, β), A, B, α)

オーバーロードされる署名として。 これは、 α他の場所によって、O時間の大きな複雑さが変わるためです。 https://github.com/JuliaLang/julia/pull/29634#issuecomment-443103667を参照して

@StefanKarpinskiのアプローチについて私が気に入っていることの1つは、時間計算量を変更せずに、 A _some_行列タイプ（たとえば、 Adjoint{_,<:SparseMatrixCSC} ）に対してmul!((Y, β), α::Diagonal, A, B)特殊なメソッドを実装できることです。 。 （これは私のアプリケーションにとって重要です。）もちろん、この方法を使用するには、特に特殊なメソッドの存在を照会する方法について、APIでさらに議論する必要があります。 それでも、APIを拡張する機会を持つことは素晴らしいことです。

誰かがメソッドのあいまいさについての私の心配を明らかにした場合、私はすべてタプルごとのアプローチになります。

これは、αの他の場所が大きなO時間計算量を変更するためです。

これは特にスパース行列ですか？ 特に密行列の場合は特にそうではありません。 リンク先の実装では、 αがAとB間にある場合を示していますか？

パッケージ開発者は実装するだけでよいと思います...

これは非常に単純化されています。 BlockArrays.jlのPseudoBlockMatrixように、ストライド行列のように動作する行列があるとします。 gemm!を完全にサポートするには、 PseudoBlockMatrixすべての順列を（1）自体、（2） StridedMatrix 、（3） Adjoint自体でオーバーライドする必要があります。 、（4） Transposeのそれ自体、（5） AdjointのStridedMatrix 、（6） TransposeのStridedMatrix 、そしておそらく他の人。 これはすでに6 ^ 3 = 216の異なる組み合わせです。 次に、 trmm!をサポートする必要があり、 UpperTriangular 、 UnitUpperTriangular 、それらの随伴、それらの転置などで同じことを行う必要があります。 次に、 gsmm!とSymmetricおよびHermitian 。

しかし、多くのアプリケーションでは、マトリックスだけでなく、それらのサブビューも処理する必要があります。特に、ブロックを処理するブロックマトリックスの場合はそうです。 次に、上記の6つの組み合わせとともに、マトリックスのビューのすべてのパーミュレーションを追加する必要があります。

これで、非常に複雑な共用体型であるStridedMatrixを含む、何千ものオーバーライドがあります。 これはコンパイラにとっては多すぎるため、 using時間は数秒ではなく数分になります。

この時点で、現在のmul! 、ひいては提案されているmul!拡張機能には設計上の欠陥があるため、パッケージ開発者は気にしないでください。 幸い、LazyArrays.jlは、特性を使用した一時的な回避策を提供します。

ですから、 @ StefanKarpinskiは、より実質的な再設計が行われるまで、物事をそのままにしておくことに同意します。設計に欠陥のあるものに労力を費やすことは、誰にとっても時間の無駄です。

@ dlfivefifty 、私はスカラー引数がどのように処理されるかについてのみ言及していました。 もちろん、現在mul!(C,A,B)すでに存在するさまざまなマトリックスタイプの複雑さはすべて残ります。

これは、αの他の場所が大きなO時間計算量を変更するためです。

これは特にスパース行列ですか？ 特に密行列の場合は特にそうではありません。 リンク先の実装では、 αがAとB間にある場合を示していますか？

@Jutho一般的に、 αを最も内側のループ位置に配置することはできないと思います。 たとえば、この場合、 α₁*A*B*α₃はサポートできますが、 A*α₂*Bはサポートできません。

https://github.com/JuliaLang/julia/blob/11c5680d5620b0b64420055e8474a2b8cf757010/stdlib/LinearAlgebra/src/matmul.jl#L661 -L670

私は、少なくとも考えるα₁またはα₂でα₁*A*α₂*B*α₃しなければなら1漸近的時間計算量の増加を避けるために。

@dlfivefiftyしかし、LazyArrays.jlでさえ、ディスパッチするためにいくつかのプリミティブ関数が必要ですよね？ 私の理解では、それは「ディスパッチ地獄」を解決しますが、人々が実装しなければならない計算「カーネル」の数を減らすことはありません。

いいえ、 Broadcasted 「プリミティブ」がないのと同じように、「プリミティブ」はありません。 しかし、現時点では、「カーネル」の問題は解決されていません。 次のステップは、 ApplyStyle怠惰なAppliedタイプを使用するように再設計することだと思います。 次に、順序が重要ではない方法で、BLASのような操作を認識するためのMulAddStyleが存在する可能性があります。

materialize!またはcopyto!をプリミティブと呼びます。 少なくとも、それはブロードキャストメカニズムの構成要素です。 同様に、LazyArrays.jlは、ある時点で、その遅延表現をループのある関数に、またはccallを外部ライブラリに下げる必要があると思います。 そのような関数の名前がmul!だとしたら、それは悪いことでしょうか？

これは非常に単純化されています。 BlockArrays.jlのPseudoBlockMatrixなど、ストライド行列のように動作する行列があるとします。 gemmを完全にサポートするために！ PseudoBlockMatrixのすべての順列を、（1）それ自体、（2）StridedMatrix、（3）それ自体の随伴、（4）それ自体の転置、（5）StridedMatrixの随伴、（6）StridedMatrixの転置、および場合によっては他のものでオーバーライドする必要があります。 。 これはすでに6 ^ 3 = 216の異なる組み合わせです。 次に、trmmをサポートしたいと思います！ そして、UpperTriangular、UnitUpperTriangular、それらの随伴、それらの転置などでも同じことをしなければなりません。 それならgsmm！ 対称およびエルミートで。
しかし、多くのアプリケーションでは、マトリックスだけでなく、それらのサブビューも処理する必要があります。特に、ブロックを処理するブロックマトリックスの場合はそうです。 次に、上記の6つの組み合わせとともに、マトリックスのビューのすべてのパーミュレーションを追加する必要があります。
これで、非常に複雑な共用体型であるStridedMatrixを含む、何千ものオーバーライドがあります。 これはコンパイラにとっては多すぎるため、使用時間は数秒ではなく数分になります。

私は確かに、現在のStridedArray型の共用体が主要な設計上の欠陥であることに同意します。 ある時点でこれを修正するあなたの試みを支持しました。

Strided.jlでは、関係するすべての行列が独自のカスタム型(Abstract)StridedViewである場合にのみ、 mul!実装します。A、B、Cの型に混合がある場合は常に、Juliaに任せます。 Base / LinearAlgebraがこれを処理します。 もちろん、これは@stridedマクロ環境で使用され、可能なすべてのBaseタイプをStridedViewタイプに変換しようとします。 ここで、 StridedViewは、サブビュー、転置と随伴、および特定の形状変更をすべて同じ（パラメトリック）タイプで表すことができます。 全体として、完全な乗算コードは約100行です。
https://github.com/Jutho/Strided.jl/blob/master/src/abstractstridedview.jl#L46 -L147
BLASが適用されない場合のネイティブのJuliaフォールバックは、そのパッケージによって提供されるより一般的なmapreducedim!機能を使用して実装され、 LinearAlgebraものよりも効率的です。 しかし、それはマルチスレッドでもあります。

漸近的な時間計算量の増加を避けるために、 α₁*A*α₂*B*α₃少なくともα₁またはα₂は1でなければならないと思います。

@tkf 、これらのスカラー係数がデフォルト値one(T) 、またはさらに良いことにtrueとる場合、定数伝播とコンパイラーの最適化により、その乗算が自動的に排除されると思います。 それがノーオペレーションであるとき、最も内側のループで。 したがって、最も一般的な形式を定義するだけでよいのです。

1 （ true ）によるすべての乗算を排除するために定数伝搬に依存できるかどうかはわかりません。 たとえば、eltypeはMatrixます。 その場合、 true * x （ x::Matrix ）は、ヒープに割り当てられたxコピーを作成する必要があると思います。 ジュリアはそれを排除するためにいくつかの魔法を行うことができますか？

@Juthoこのベンチマークは、Juliaが中間の乗算を排除できない場合があることを示していると思います。

function simplemul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)
    <strong i="7">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="8">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="9">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="10">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(α₁ * A[i, 1] * α₂ * B[1, j] * α₃ +
                   α₁ * A[i, 1] * α₂ * B[1, j] * α₃)
        for k = 1:size(A, 2)
            acc += A[i, k] * α₂ * B[k, j]
        end
        Y[i, j] = α₁ * acc * α₃ + β₁ * Y[i, j] * β₂
    end
    return Y
end

function simplemul!((Y, β), A, B, α)
    <strong i="11">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="12">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="13">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="14">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(A[i, 1] * B[1, j] * α +
                   A[i, 1] * B[1, j] * α)
        for k = 1:size(A, 2)
            acc += A[i, k] * B[k, j]
        end
        Y[i, j] = acc * α + Y[i, j] * β
    end
    return Y
end

fullmul!(Y, A, B) = simplemul!((false, Y, false), true, A, true, B, true)
minmul!(Y, A, B) = simplemul!((Y, false), A, B, true)

using LinearAlgebra
k = 50
n = 50
A = [randn(k, k) for _ in 1:n, _ in 1:n]
B = [randn(k, k) for _ in 1:n]
Y = [zeros(k, k) for _ in 1:n]
<strong i="15">@assert</strong> mul!(copy(Y), A, B) == fullmul!(copy(Y), A, B) == minmul!(copy(Y), A, B)

using BenchmarkTools
<strong i="16">@btime</strong> mul!($Y, $A, $B)     # 63.845 ms (10400 allocations: 99.74 MiB)
<strong i="17">@btime</strong> fullmul!($Y, $A, $B) # 80.963 ms (16501 allocations: 158.24 MiB)
<strong i="18">@btime</strong> minmul!($Y, $A, $B)  # 64.017 ms (10901 allocations: 104.53 MiB)

素晴らしいベンチマーク。 私はまた、いくつかの同様の実験によってこれらの割り当てが実際に排除されないことにすでに気づいていました。 このような場合、 *(::One, x::Any) = xと*(x::Any, ::One) = xを定義するだけの特別な目的のOneシングルトンタイプを定義すると便利な場合があります。ユーザータイプを定義する必要はありません。 その場合、少なくともα₂のデフォルト値は、 One()ます。

ああ、はい、それは賢いです！ 最初はα₁ * A * α₂ * B * α₃をサポートしても大丈夫だと思っていましたが、別の問題が見つかったと思います。たとえば、 Aが行列の行列である場合に何をすべきかは数学的にあいまいです。 α₁は行列です。 α位置で非スカラー引数をサポートしない場合は、問題にはなりません。 ただし、 mul!((β₁, Y, β₂), args...)のメンタルモデルとしてY .= β₁*Y*β₂ + *(args...)を提示することは不可能です。 さらに、対角行列をα₁またはα₂に渡すことができれば、ほとんど「無料」で計算できる場合があります（アプリケーションでは重要です）。 私は2つのルートがあると思います：

（1） mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)が、メソッドをオーバーロードする場合、引数αおよびβはDiagonal受け入れる必要があります。 エンドユーザーコードがスカラー値を介して呼び出すことができるように、呼び出しパスを定義するのは簡単です。 ただし、これを効率的に機能させるには、 Diagonal(fill(λ, n)) https://github.com/JuliaLang/julia/pull/30298#discussion_r239845163の「O（1）バージョン」をLinearAlgebraに実装する必要があります。 スカラーと対角α実装はそれほど違いがないことに注意してください。 多くの場合、 αとα.diag[i]交換するだけです。 ですから、パッケージの作者にとってはそれほど負担にはならないと思います。

Aが行列の行列であり、 αがeltypeとして扱われるべき行列である場合、 mul!(Y, α * I, A, B)呼び出すことができるため、これにより上記のあいまいさが解消されます。 eltype A 。

（2）上記のルート（1）はまだ複雑すぎますか？ もしそうなら、今のところ代わりにmuladd!で行ってください。 mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)をサポートしたい場合は、下位互換性を維持しながら移行することは難しくありません。

この時点で、この一般的な署名に対してのみ機能するように定義されている、非常に制限された特殊なmatmul!(C, A, B, α, β)だけを使用するべきではないかどうか疑問に思う必要があります。

matmul!(
    C :: VecOrMatT,
    A :: Matrix{T},
    B :: VecOrMatT,
    α :: Union{Bool,T} = true,
    β :: Union{Bool,T} = false,
) where {
    T <: Number,
    VecOrMatT <: VecOrMat{T},
}

また、この署名を書き込んでディスパッチできるのは本当に素晴らしいことです。

それは本質的に私の提案です（2）、そうですか？ （ A :: Matrix{T}は文字通りCore.Array{T,2}意味するのではないと思います;それ以外の場合は多かれ少なかれgemm! ）

私はそれを一時的な解決策として満足し、私が維持しているパッケージで部分的にサポートできます（未解決の特性の問題のために「部分的」）が、ミックスに別の名前を追加します： mul! 、 muladd!そして今matmul! 。

...誰かが「トリアージは...」と投稿してそれを呼び出す時間ではありませんか？

また、この署名を書き込んでディスパッチできるのは本当に素晴らしいことです。

これをmul!メソッドにするだけで、この署名を正確に引数としてきれいにディスパッチできるという事実ではありません。 その後、より一般的な解決策が発生した場合に備えて、完全に非推奨にすることもできます。

これをmul!メソッドにします

mul!(C, A, B, α, β)する場合、互換性を損なうことなく、 mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)などに一般化する方法はありません。 （私たちはこの議論から永遠に自由なので、多分それは「機能」です：smile :)。

また、要素タイプをNumberバインドし、現在の3引数mul! （すでにNumber要素タイプをサポートしている）との互換性を維持すると、多くのことが導入されることに注意してください。重複の。

mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)に何が期待できるかわかりません...だから、それは機能だと思います。

バンプ。 インプレースパフォーマンスを向上させるために、どこでもBLAS関数を使用しなければならないのは悲しいことです。

@StefanKarpinskiトリアージでそれを持ち出すことができますか？

何人かのlinalgの人が電話に出ない場合、どのような結果になるかはわかりませんが、最近は通常はありませんが、話し合うことができます。 率直に言って、私はこの議論をある種の解決に向けようとかなりの時間と労力を費やしました、そしてすべてのアイデアは何らかの形で着実に拒否されたようです、それで私はほとんどこの問題をチェックアウトしましたこの点。 誰かが問題の要約を作成し、さまざまな提案が不十分である理由を説明できれば、それは生産的なトリアージの議論に役立ちます。 そうでなければ、私たちは多くのことができるとは思いません。

コンセンサスの欠如は、これをStdLibに組み込むのに適切な時期ではないことを意味すると思います。

ダウンユーザーが使用できる提案の1つを実装するパッケージMatMul.jlだけではないのはなぜですか？ StdLibにいることが実際にそれほど重要である理由がわかりません。 私が維持しているパッケージでこれを喜んでサポートします。

ジュリアンバージョンのgemmを考えています。 とgemv！ SparseArraysにすでにあるものと一致します。 上記の@andreasnoackによると：

すでにmul!(C, A, B, α, β)落ち着き、デフォルト値はα 、 βだと思いました。 このバージョンを使用しています

julia / stdlib / SparseArrays / src / linalg.jl

b8ca1a4の32行目から50行

..。
一部のパッケージもこのフォームを使用していると思いますが、頭の中でどれを使用しているか覚えていません。

その提案には7つの親指があり、親指は下がっていませんでした。 密なベクトル/行列に対してその関数を実装しないのはなぜですか？ それは、最も一般的なユースケースをカバーする単純なソリューションでしょうか？

OK。 ですから、コンセンサスがあるかどうかについてのコンセンサスさえないのではないかと思います：sweat_smile：

_I_は、ほとんどすべての人[*]がこのAPIを望んでいると考えていました。これは、関数名と署名の問題です。 このAPIを持っていないことと比較すると、誰もがどのオプションにも満足していると思いました（たとえば、 mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) 、 muladd!(C, A, B, α, β) 、 mul!(C, A, B, α, β) ）。 特定のAPIがそれを持っていないよりもはるかに悪いという説得力のある議論を誰かができない限り、トリアージが決定するものは何でも満足します。

@StefanKarpinskiただし、ディスカッションがまだ十分に統合されていないと思われる場合は、 triageタグを削除してください。

[*] OK、 @ dlfivefifty 、現在の3引数mul!さえ疑わしいと思います。 しかし、それには3引数のmul!インターフェイスを最初から変更する必要があるため、これはこの説明の範囲をはるかに超えていると思いました（これは、5引数のバリアントの何らかの形式を追加することについて解釈してきました）。 LazyArrays.jlが成熟するまで「十分に」機能するものが必要だと思います。

ダウンユーザーが使用できる提案の1つを実装するパッケージMatMul.jlだけではないのはなぜですか？

@dlfivefiftyこれはインターフェイス関数（オーバーロード可能なAPI）であるため、LinearAlgebra.jlに含めることが重要だと思います。 また、 mul!(C::AbstractMatrix, A::AbstractVecOrMat, B::AbstractVecOrMat)はLinearAlgebra.jlに実装されているため、 MatMul.muladd! mul!を定義することはできません。 もちろん、いくつかの回避策がありますが、特に名前と署名を決定する必要があるのは「のみ」であることを考えると、単純な実装を使用する方がはるかに優れています。

密なベクトル/行列に対してその関数を実装しないのはなぜですか？

@chriscoey残念ながら、これだけが誰にとってもお気に入りではありません： https ：//github.com/JuliaLang/julia/issues/23919#issuecomment-441717678。 これは、このオプションと他のオプションの長所と短所の要約ですhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-441865841 。 （他の人のコメントも参照してください）

トリアージから：コンパイラのサポートやBLASへの選択など、一般的なテンソルの縮約APIを長期的に計画していますが、中期的には、差し迫ったニーズに対応するAPIを選択するだけです。 BLASと一致する場合は、BLAS名を選択するのが妥当と思われます。

@Keno 、一般的なテンソルの縮約APIとコンパイラのサポートについて共有できる情報はありますか？ （まだ）公開されていませんが、共有できる興味深い情報があるかもしれません。

APIの設計はこれまで行われていません。一般的な意味で、APIの設計が必要です。 あなたはこれらのいくつかに取り組んでいることを知っているので、適切な時期にデザインセッションを行うのは良いことですが、私たちはまだそこにいるとは思いません。

BLASと一致する場合は、BLAS名を選択するのが妥当と思われます。

これは、一般的な線形代数関数名に対してこれまで行ってきたこととは完全に反対です。

強い/弱いの計画何β == 0の提案一般的なバージョンではBLAS.gemm!(α, A, B, β, C) ？

BLAS呼び出しに下げると、これはlmul!と矛盾しますが、強いゼロのように動作します。 β == 0場合、 generic_muladd!フォールバックする以外に、これに対する解決策を考えることはできません。

強い/弱いβ== 0の計画は何ですか

https://github.com/JuliaLang/julia/issues/23919#issuecomment -430139849で私のコメントの周りで簡単に議論されただけなので、トリアージはおそらくその質問に対処しませんでした。

@Keno APIの設計はまだありませんが、「コンパイラのサポートとBLASへの選択を含むAPI」は、突然変異として定義されるのでしょうか、それともXLA線形代数のように不変であると思いますか。コンパイラ？ つまり、 mul!やmuladd!はそのようなAPIの一部になると思いますか？

https://github.com/JuliaLang/julia/issues/23919#issuecomment-475534454の@andreasnoackの質問に対して@Kenoにpingを実行します

申し訳ありませんが、私はこの問題に戻るつもりでした（特にトリアージを要求しました）が、トリアージからの決定が次のアクションに与えられるかどうかわかりませんでした。

BLASと一致する場合は、BLAS名を選択するのが妥当と思われます。

@andreasnoackが指摘したように、行列とベクトルの乗算などをサポートする必要があるため、（たとえば） gemm!使用することはできません。 ;そうではありません）。

差し迫ったニーズに対応するAPIを選択するだけです。

だから、私たちはこの方向に従うことができると思います。 @StefanKarpinskiによって提案されたタプルベースのAPIを忘れて、 mul! / muladd! / addmul!いずれかを「ただ」選択することを意味すると思います。

元の議論に戻ります。 しかし、APIについてもう議論しないという制約があるのはいいことだと思います。

mul! / muladd! / addmul!から名前を選ぶ方法

@chriscoey将来のAPIについては他の場所で議論する方が良いと思います。 この問題はすでに非常に長く、中期的な解決策に焦点を当てない限り、進展を遂げることはできません。 新しい号（または談話スレッド）を開くのはどうですか？

私は、今から10日の期限で1回の承認投票を提案します。 承認投票とは、誰もが議論を続けるよりも好ましいと考えるすべてのオプションに投票することを意味します。 継続的な議論よりも今は自分の最も嫌いな名前を持ちたい人は、3つすべてに投票する必要があります。 広範な承認を受けるオプションがない場合、または投票スキーム自体が広範な承認を満たしていない場合は、議論を継続する必要があります。 承認されたオプションがほぼ同点の場合、 @ tkfが決定します（PR作成者の特権）。

+1：私はこの投票スキームに同意し、承認票を投じました。
-1：私はこの投票スキームに同意しません。 あまりにも多くの、またはあまりにも重要な人々がこのオプションを選択した場合、投票は無効になります。

心： mul!は、継続的な議論よりも望ましいです。
ロケット： muladd!は、継続的な議論よりも望ましいです。
Hooray：継続的な議論よりもaddmul!が望ましいです。

私は暫定的に、75％の承認と5人が確実に定足数を作成することを提案します（つまり、投票手順全体への不一致を含め、投票した人の75％、および少なくとも5人が勝利オプションを承認しました。参加が少ない場合、次に5/6または6/8が定足数を作成しますが、全会一致の4/4は失敗と見なされる可能性があります）。

1.3の機能凍結は8月15日頃です： https ：

また、名前の決定と直交するβ == 0 https://github.com/JuliaLang/julia/issues/23919#issuecomment-475420149の動作も決定する必要がありundefを処理するためにそこで使用したアプローチ）。 レビュー中に他の問題が見つかる場合があります。 だから、1.3に入ることができるかどうかはわかりません...。

Re： β == 0 、 @ andreasnoackのコメントhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-430139849 （私の要約： β == 0処理はBLASである必要があります-BLASを可能な限り活用するための互換性）は理にかなっています。 すぐ下の@simonbyrneの議論以外に反対意見を見つけるのは難しいです（「すべての実装にはゼロをチェックするためのブランチが必要です」）。 β == 0処理のようなBLASに反対する他の議論はありますか？

@simonbyrneコメントhttps://github.com/JuliaLang/julia/issues/23919#issuecomment-430375349に関しては、明示的な分岐はほとんどが1つの線形β != 0 ? rmul!(C, β) : fill!(C, zero(eltype(C)))ため、大きな問題ではないと思います。 また、 C = Matrix{Any}(undef, 2, 2)など、処理する必要がある非常に一般的な実装の場合、実装にはとにかく明示的な「ストロングゼロ」処理が必要です（私のPR https：// githubのヘルパー関数_modify!を

高性能の弱い零点を持つことは可能ですか？ 私たちが望むという意味で：

julia> A = [NaN 0;
                     1 0]

julia> b = [0.0,0];

julia> 0.0*A*b
2-element Array{Float64,1}:
 NaN  
   0.0

julia> false*A*b
2-element Array{Float64,1}:
 0.0
 0.0

つまり、BLAS（強い0を使用）に下げる場合、どの行がNaNかを手動で決定する必要があります。

@dlfivefifty BLASはAとBでNaNを処理できると思いますが、 Cませんか？

BLAS.gemm!などを使用してNaN対応の_C =α* A * B + 0 * C_を効率的に実行する方法はないと思います[1]。ここから、 @ andreasnoackの引数が出てきます。

[1] isnan.(C)どこかに保存し、後でCを「汚染」する必要があります

@chethega投票から10日以上経ちました

@chriscoeyそうです、投票は締め切られました。

私はgithubが苦手で、投票した人の完全なリストを取得できません（これは、投票した人の数を計算するために必要です）。 しかし、数字を見ると、 mul!が圧倒的なサポート（おそらく75％の承認クォーラムを管理している）を持っていることは明らかであり、2番目の候補muladd!は50％をはるかに下回っています。

投票スキームに対する異議は1つもありませんでした。 私は投票を呼び、 mul!が勝ち、名前が決定しました。 @tkfはそれを飛ばし

@chethegaありがとう、これを決めるのにいいスキームでした！

ところで、私はすぐにリベースを行うことはできません（しかし、おそらく数週間以内に）ので、誰かがリベースまたは再実装をしたい場合は、私を待ってはいけません。

残念ながら、NaNセマンティクスには投票できませんでした。 機能の凍結は来週であり、意味のある投票を行うための十分な時間がありません。

拘束力のない国民投票でスレッドのムードのスナップショットを収集することを提案します。

次のオプションが表示されます。

1. 議論を続け、締め切り前に何らかの形でコンセンサスが得られることを期待するか、コアの人々が私たちに延長などを許可します。 ：tada ：（説明のために編集：これはデフォルトのオプションです。つまり、別のオプションについて合意に達することができない場合にどうなりますか。最も可能性の高い結果は、5引数mul!が1.4まで遅延することです。）
2. 未定義のNaN動作をバックストップとして、新機能をマージします。 コンセンサスに達するとすぐに、コードやドキュメントを更新して、決定されたNaNの動作（強いゼロと弱いゼロ）を取得します。 未定義の実装定義のNaN動作のバックストップは、最終的には無期限になる可能性がありますが、それは今日の投票には向いていません。 （最速のものを実装します。気になるユーザーはさまざまなメソッドを呼び出す必要があります）。 ：いいぞ：
3. ジェムはジェムを意味します！ 1.3でマージし、強力なゼロへのコミットメントを文書化します。 ：ハート：
4. NaNはNaN意味します！ 弱いゼロへの文書化されたコミットメントで1.3にマージします。 ：目：
5. 1.3の崖にぶつかる前に、何かをしてください。 ：ロケット：
6. 投票を拒否します。 ：拒絶：
7. で書きます
8. 提案されたダウンスレッド：代替のバックストップ配置。 後でより検討された決定に到達できるまで、すばやくマージし、1.3アルファの弱い/強いゼロ発散をエラーにするようにしてください。 つまり、 !(alpha === false) && iszero(alpha) && !all(isfinite, C) && throw(ArgumentError())とマージし、このエラーチェックが廃止されて他の何かが優先される可能性があることを文書化します。 ：混乱：

複数の、おそらく矛盾するオプションを自由に選択してください。@ tkf /トリアージは、投票を無視する可能性があります。

編集：現在、：tada :(忍耐）と：rocket :(忍耐）のみが矛盾していますが、どちらも他のすべてと互換性があります。 ダウンスレッドで明確にされているように、トリアージは、水14日から木15日までの不特定の日付での投票結果をカウントし、不特定の方法でそれを考慮に入れることを願っています。 これも「承認投票」を意味します。つまり、お気に入りのオプションだけでなく、好きなオプションをすべて選択します。 ：rocket：は：thumbsup：、：heart：、：eyes ：、および：confused：を不承認にしないことが理解されます。 今回の世論調査は前回よりも急いでいることをお詫び申し上げます。

「Mergefor1.3」ではなく「Mergefor1.x」の場合は、ストロングゼロ（：heart :)に投票します。 すべての「Mergefor1.3」が「Merge1.x」である場合、オプションは意味がありませんか？

@chethegaに感謝します。 @tkf私は本当に新しいmulを必要とする立場にあります！ NaNの決定をあまり気にせずにできるだけ早く（パフォーマンスが低下しない限り）。

LazyArrays.jlをチェックしましたか？ 参考までに、それは本当に素晴らしい融合行列乗算サポートを持っています。 BLAS.gemm!などはパブリックメソッドであるため、安全に使用することもできますhttps://docs.julialang.org/en/latest/stdlib/LinearAlgebra/#LinearAlgebra.BLAS.gemm！

私は実際にジェネリックmulが本当に必要です！ さまざまな最適化問題を最も効率的に表現するために、さまざまな構造化されたスパースでプレーンな古い密行列を使用しているためです。 私は一般性とスピードのためにここにいます。

そうですか。 そして、LazyArrays.jlで話し合ったことを思い出したので、もちろんあなたはすでにそれを知っていました...

「ASAP」に関して、ジュリアの4か月のリリースサイクルは、少なくとも設計として、機能がフリーズする直前の「マージラッシュ」を回避するためのものです。 私は以前に同じことを試したことがあるので、これを言うのは公平ではないことを知っています...しかし、誰かがこれを思い出させるために言及する必要があると思います。 明るい面は、ジュリアは非常に簡単に作成できることです。 マージ後すぐに次のリリースまで使用を開始できます。

編集：リリース->マージ

ありがとう。 締め切りは有益な動機付けになると思います。これが再び古くなるのを避けたいと思います。 ですから、締め切りを目標にしようと提案したいと思います。

このスレッドに積極的にエネルギーを注入しているのは素晴らしいことです！

私は実際にジェネリックmulが本当に必要です！ さまざまな最適化問題を最も効率的に表現するために、さまざまな構造化されたスパースでプレーンな古い密行列を使用しているためです。 私は一般性とスピードのためにここにいます。

5つの引数mul!は、さまざまなタイプがある場合はうまく機能しません。あいまいさを避けるために、組み合わせて多くのオーバーライドが必要になります。 これは、LazyArrays.jl MemoryLayoutシステムの背後にある動機の1つです。 BandedMatrices.jlおよびBlockBandedMatrices.jlでは、まさにこの理由から、「構造化されたスパース」行列に使用されます。 （ここでは、帯行列のサブビューでさえ、帯BLASルーチンにディスパッチされます。）

おかげで、私はLazyArraysをもう一度試してみます。

5引数のmulは一般的に一時的な一時的なギャップと見なされているようです（LazyArraysのようなソリューションが2.0で使用できるようになるまで）ので、長期的には必ずしも理想的または完璧なソリューションでなくても、マージすることを目指すことができると思います。

@chethega新しい拘束力のない投票の集計をいつカウントする必要があると思いますか？

@tkf確かに、強い/弱い/ undefのゼロは1.xでも意味があります。

ただし、1.4まで待って5引数のmul!を取得するよりも、1.3 mul!を使用したいという人はかなり多いと思います。 締め切りがなかったら、もう少し待って、適切な投票を行う方法を考えるのにもう少し時間がかかります（投票には少なくとも10日）。 最も重要なことは、弱い/強いゼロの速度と優雅さについて競合する実装を最初に提示してベンチマークすることなしに、意味のある投票を行うことはできません。 個人的には、最初にiszero(alpha)チェックし、次にマトリックスをスキャンして!isfinite値を探し、次に追加の割り当てを伴う低速パスを使用することで、弱いゼロを強いゼロとほぼ同じ速度で作成できると考えています。 しかし、とにかく強いゼロセマンティクスを好みます。

@chethega新しい拘束力のない投票の集計をいつカウントする必要があると思いますか？

トリアージは今週、1.3アルファの決定（遅延/強い/弱い/バックストップ）を行う必要があります。 15日木曜日または14日水曜日は、トリアージがカウントされ、それを考慮に入れるための賢明なオプションだと思います。 私はおそらく木曜日には参加できないので、他の誰かが数える必要があります。

現実的には、ここで保守的になり、締め切りに間に合わず、議論を続けて1.4を待つことは問題ありません。

一方、私たちはそれに気付かずにすでに合意に達しているかもしれません。 @ andreasnoackは、ゼロ係数は強いゼロであるべきだといういくつかの強力な議論をしました。 彼がすべての弱いゼロ支持者を納得させることができたのかもしれません。 おそらく昨年は、5引数のマルチを本当に望んでいて、この小さな詳細についてはあまり気にしていない大多数の人がいる可能性があります。 もしそうなら、誰も議論を止めたくないという理由だけで、機能をさらに遅らせるのは残念だろう。

今のところエラーをスローしないのはなぜですか？

β == 0.0 && any(isnan,C) && throw(ArgumentError("use β = false"))

今のところエラーをスローしないのはなぜですか

そのオプションを投票に追加しました。 素晴らしい妥協案！

期待を設定するだけです。1.3の機能フリーズは3日以内であるため、基本的にこれが間に合うようにする方法はありません。 タイミングを実際に制御できるのはリリースサイクルの唯一の部分であるため、機能のフリーズと分岐についてはかなり厳格に取り組んでいます。

ただし、作業はhttps://github.com/JuliaLang/julia/pull/29634ですでに行われてい

@tkf for＃29634まだ実行されていない作業をリストできますか（投票に応じて名前を変更したり、ゼロを処理したりすることを含む）？ あなたが忙しいので、残りのToDoを分割して、負担が二度とかからないようにする方法を見つけることができるかもしれません。

私がATMについて考えることができるTODOは次のとおりです。

• リベース
• 名前を変更addmul! -> mul!
  
  
  
  • 新しいAPIがmul!と呼ばれないと想定してコードを調整します（例： <strong i="15">@deprecate</strong> mul!(C, A, B, α, β) addmul!(C, A, B, α, β) ）
  
  
• MulAddMulなどの実装戦略についてコア開発者からOKを取得します。 https://github.com/JuliaLang/julia/pull/29634#issuecomment-440510551を参照して@andreasnoack 、あなたはそれを見る機会がありましたか？
• 理想的には、 Quaternionを使用してテストを追加します。 https://github.com/JuliaLang/julia/pull/29634#issuecomment-443379914を参照して

私のPRは、 β = 0処理のBLASセマンティクスを実装しています。 したがって、エラーのスローなどの他の処理も実装する必要があります。

私のPRは、 β = 0処理のBLASセマンティクスを実装しています。

申し訳ありませんが、私の記憶は古くなっていました。 私の実装は一貫性がなく、NaNを_時々_伝播します。 したがって、追加のTODOは、 β = 0.0一貫させることです。

MulAddMulタイプは、内部で使用するためのものですよね？

はい、それは完全に内部の詳細です。 私の心配は、（1）専門分野が多すぎる可能性があり（beta = 0などがtypeパラメーターにエンコードされている）、（2）ソースコードの可読性が低下することでした。

それらは有効な懸念事項です。 線形代数コードではすでに大量の特殊化を行っているので、ここで本当に特殊化する必要があるかどうかを検討することをお勧めします。 私の考えでは、小さな行列は無料ではなく（あなたが言ったように、ソースコードが複雑になり、コンパイル時間が長くなる可能性があるため）、小さな行列の乗算にはStaticArraysを使用する方がよいと考えています。 したがって、私は実行時に値をチェックすることに傾倒していますが、気が変わった場合はいつでもこれを調整できるので、これによって遅延が発生することはありません。

参考までに、ソフトゼロには単純な実装があります。

if iszero(β) && β !== false && !iszero(α)
   lmul!(zero(T),y) # this handles soft zeros correctly
   BLAS.gemv!(α, A, x, one(T), y) # preserves soft zeros
elseif iszero(α) && iszero(β)
   BLAS.gemv!(one(T), A, x, one(T), y) # puts NaNs in the correct place
   lmul!(zero(T), y) # everything not NaN should be zero
elseif iszero(α) && !iszero(β)
   BLAS.gemv!(one(T), A, x, β, y) # puts NaNs in the correct place
   BLAS.gemv!(-one(T), A, x, one(T), y) # subtracts out non-NaN changes
end

@andreasnoack申し訳ありませんが、 mul!(C, A::BiTriSym, B, α, β) https://github.com/JuliaLang/julia/pull/29634#issuecomment -440510551のようないくつかの構造化行列の最も内側のループを最適化するために、実際に特殊化が必要であることを忘れました。 一部の特殊化は削除できますが、実際にはより多くの作業が必要になります（遅延が発生します）。

したがって、私は実行時に値をチェックすることに傾倒していますが、気が変わった場合はいつでもこれを調整できるので、これによって遅延が発生することはありません。

すごい！

https://github.com/JuliaLang/julia/pull/29634で修正

@andreasnoackこれを時間内にレビューしてマージしてくれてありがとう！

1.3でマージされたので、実装について非常に緊張しました： smile:。 1.3-rcがリリースされたときに、ここの人々が線形代数コードをより徹底的にテストできることを感謝します！

心配する必要はありません。1.3RC+ PkgEvalsがバグを取り除くのに十分な時間があります。