前の問題への論理後継...👍

配列上で要素ごとに動作するconjの動作は、Matlabからの不幸なホールドオーバーのようなものであり、数学的に正当な操作ではありません。

これはまったく真実ではなく、 expまったく類似していません。 複雑なベクトル空間とその活用は、完全に確立された数学的概念です。 https://github.com/JuliaLang/julia/pull/19996#issuecomment-272312876も参照して

複雑なベクトル空間とその共役は、完全に確立された数学的概念です。

私が間違っていない限り、その文脈での正しい数学的活用操作は、 ctransposeではなくconj （これはまさに私のポイントでした）：

julia> v = rand(3) + rand(3)*im
3-element Array{Complex{Float64},1}:
 0.0647959+0.289528im
  0.420534+0.338313im
  0.690841+0.150667im

julia> v'v
0.879291582684847 + 0.0im

julia> conj(v)*v
ERROR: DimensionMismatch("Cannot multiply two vectors")
Stacktrace:
 [1] *(::Array{Complex{Float64},1}, ::Array{Complex{Float64},1}) at ./linalg/rowvector.jl:180

recurキーワードを使用する場合の問題は、最後に確認したところ、キーワードを使用するとパフォーマンスが大幅に低下することです。これは、これらの関数をベースケースで再帰的に呼び出す場合に問題になります。スカラー。

とにかく、1.0でキーワードのパフォーマンスの問題を修正する必要があります。

@StefanKarpinski 、あなたは間違っています。 随伴を持たずにベクトル空間で複素共役を持つことができます—随伴は、複雑なベクトル空間だけでなく、ヒルベルト空間などを必要とする概念です。

さらに、ヒルベルト空間がある場合でも、複素共役は随伴とは異なります。 たとえば、ℂⁿの複素列ベクトルの共役は別の複素ベクトルですが、随伴作用素は線形演算子（「行ベクトル」）です。

（複素共役は、 conj(v)*v乗算できることを意味するものではありません！）

ベクトル化されたconj非推奨は、残りの提案とは無関係です。 ベクトル空間での複素共役の定義に関する参考資料をいくつか提供できますか？

https://en.wikipedia.org/wiki/Complexification#Complex_conjugation

（この扱いはかなり形式的ですが、「複素共役行列」または「複素共役ベクトル」をグーグルで検索すると、無数の使用法が見つかります。）

複素ベクトルを共役ベクトルにマッピングすること（ conjが現在行うこと）が共役コベクトル（ 'が行うこと）とは異なる重要な操作である場合、 conj確実に維持できます。 conjとadjointはスカラーに同意しますが、配列では動作が異なるため、これにより区別されます。

その場合、 conj(A) conjは各要素でadjoint呼び出す必要がありますか？ 2x2行列の例としての複素数の表現は、 conj呼び出すのではなく、 conj(A)が実際に各要素でadjointを呼び出す必要があることを示唆します。 これにより、 adjoint 、 conj 、およびconj.すべて異なる操作になります。

1. adjoint ： iとjインデックスを交換し、要素にadjointを再帰的にマッピングします。
2. conj ：要素にadjointをマップします。
3. conj. ：要素にconjをマップします。

conj(A)は、各要素でconjを呼び出す必要があります。 複素数を2x2行列で表す場合、異なる複素数ベクトル空間があります。

たとえば、ベクトルの共役の一般的な使用法は、実数行列の固有値の分析です。固有値と固有ベクトルは、複素共役のペアで提供されます。 ここで、実数の2x2行列の2d配列Aで表されるブロック行列があり、2成分ベクトルの1d配列で表されるブロックベクトルvに作用するとします。 以下のための任意の固有値λのA固有ベクトルでv 、我々は期待して二固有値conj(λ)固有ベクトルとconj(v) 。 conjがadjoint再帰的に呼び出す場合、これは機能しません。

（最も一般的な方法で定義された線形演算子の随伴は内積の選択にも依存するため、行列の場合でも随伴は共役転置とは異なる場合があることに注意してください。実際のアプリケーションの多くは、加重内積の種類が適切であり、その場合、行列の随伴をとる適切な方法が変わります！しかし、 Matrix与えられると、によって与えられる標準の内積に対応する随伴をとるべきであることに同意します。 dot(::Vector,::Vector) 。ただし、一部のAbstractMatrix （または他の線形演算子）タイプがadjointをオーバーライドして別のことを実行する可能性は十分にあります。）

これに対応して、3d配列を線形演算子として定義していないため（たとえば、組み込みのarray3d * array2d演算がないため）、たとえば3d配列に対して代数的に妥当なadjoint(A)を定義することにもいくつかの困難があります。 。 たぶんadjointは、スカラー、1D、および2D配列に対してのみデフォルトで定義する必要がありますか？

更新：ああ、いいですね：3D配列にもctranspose定義していません。 続ける。

（OT：大成功を収めた6部構成のミニシリーズの次の記事である「7テンソルを真剣に受け止める」ことをすでに楽しみにしています...）

複素数を2x2行列で表す場合、異なる複素数ベクトル空間があります。

私はこれに従っていません–複素数の2x2行列表現は、要素として複素スカラーを持つのとまったく同じように動作するはずです。 私は、例えば、私たちが定義すると

m(z::Complex) = [z.re -z.im; z.im z.re]

そして、任意の複素数ベクトルv場合、このIDを保持する必要があります。

conj(m.(v)) == m.(conj(v))

例をもっと詳しく説明して、すでにmと通勤しているはずの'と比較しますが、 。誤ってその通勤をm.(v)' == m.(v')が保持されますが、私があなたを正しく理解している場合は、 @ stevengj 、 conj(m.(v)) == m.(conj(v))はすべきではありませんか？

conj(m(z))は== m(z)ます。

あなたのm(z)は、加算と乗算の下での複素数の同型ですが、線形代数の他の方法では同じオブジェクトではないので、 conjふりをするべきではありません。 たとえば、 zが複素数スカラーの場合、 eigvals(z) == [z]ですが、 eigvals(m(z)) == [z, conj(z)]です。 m(z)トリックが複雑な行列に拡張されると、このスペクトルの2倍は、たとえば反復法に対してトリッキーな結果をもたらします（たとえばこの論文を参照）。

別の言い方をすれば、 zはすでに複素数ベクトル空間（複素数上のベクトル空間）ですが、2x2実数行列m(z)は実数上のベクトル空間です（あなた掛けることができますm(z)実数による）...あなたは"complexify"場合はm(z)複素数を乗じて例えばm(z) * (2+3im) （ないm(z) * m(2+3im) ）あなた元の複素ベクトル空間z同形ではなくなった別の複素ベクトル空間を取得します。

この提案は、実際の改善をもたらすように見えます：+1：私は数学的な側面について考えています：

• 私が理解しているように、活用は、ベクトル空間/ベクトルの係数を提供するリング（読み取り：数値）に対するアクションです。 このアクションは、リング上のベクトル空間の構築の線形性によって、共役とも呼ばれるベクトル空間（およびそのマッピング、read：matrices）に対して別のアクションを引き起こします。 したがって、共役は必然的に係数への要素ごとの適用によって機能します。 Juliaの場合、これは、ベクトルv 、 conj(v) = conj.(v)中心にあることを意味し、 conjに配列用のメソッドがあるか、スカラー専用のメソッドがあるかは設計上の選択です。どちらも大丈夫そう？ （complex-numbers-as-2x2-matricesの例に関するStevenのポイントは、これは係数が形式的/実際に実数であるベクトル空間であるため、活用はここでは効果がないということです。）
• adjoint密接に線形代数を含む重要なドメインの多くの基本的なのです代数的な意味を持っている（参照1と2と3 、あまりにも物理学の大きなアプリケーションで、すべてを）。 adjointが追加された場合、検討中のアクションのキーワード引数を許可する必要があります。ベクトル空間/関数解析では、このアクションは通常、内積によって誘導されるため、代わりにキーワード引数を形式にすることができます。 ジュリアの転置のために設計されたものは、これらのアプリケーションとの競合を避ける必要があるので、 adjointは少し高額だと思いますか？

@felixrehren 、随伴を誘発する内積を指定するためにキーワード引数を使用することはないと思います。 ベクトルのdotの意味を変更したい場合と同じように、代わりに別の型を使用すると思います。

私の好みは少し簡単でしょう：

• conjそのまま（要素ごとに）保持します。
• a'をadjoint(a)に対応させ、常に再帰的にします（したがって、要素にadjointが定義されていない文字列の配列などでは失敗します）。
• a.'をtranspose(a)に対応させ、再帰的ではないようにし（ permutedims ）、要素のタイプを無視します。

非再帰的なadjointユースケースは実際には見当たりません。 一気に、再帰的なtransposeユースケースを想像することができますが、 a.'をtranspose(a, recur=true)に変更する必要があるアプリケーションでは、同じように簡単に思えます。別の関数transposerecursive(a)呼び出します。 Baseでtransposerecursiveを定義することもできますが、これが必要になることはめったにないので、実際に表示されるかどうかを確認する必要があります。

私は個人的に、これを単純に保つことがユーザーにとって（そして実装にとって）最も簡単であり、それでも線形代数の面でかなり防御できると感じています。

これまでのところ（ほとんどの）線形代数ルーチンは、標準の配列構造と標準の内積にかなり強く根ざしています。 行列またはベクトルの各スロットに、「フィールド」の要素を配置します。 私は、フィールドの要素のために、私たちは気にすることを主張するだろう+ 、 * 、など、およびconjではなく、 transpose 。 フィールドが2x2の実数行列に少し似ているが、 conj下で変化する特別な複雑な表現である場合、それは問題ありません-それはconjプロパティです。 conj下で変化しないのが2x2の実際のAbstractMatrixある場合、おそらく、行列のそのような要素は随伴作用素の下で変化するべきではありません（ @stevengjは私が説明できるよりも良いと言いました-複素数と同型である可能性がありますが、それはすべての点で同じように動作するという意味ではありません）。

とにかく、2x2の複雑な例は、私には少し赤いニシンを感じます。 再帰行列の動作の本当の原因は、ブロック行列で線形代数を実行するためのショートカットでした。 この特別なケースを適切に扱い、基盤となるシステムを簡素化してみませんか？

したがって、私の「単純化された」提案は次のようになります。

• conjそのまま維持します（またはAbstractArrayのビューにします）
• a'を(a')[i,j] == conj(a[j,i])ような非再帰的なビューにします
• a.'を(a.')[i,j] == a[j,i]ような非再帰的なビューにします
• ブロック行列などを処理するためのBlockArrayタイプを導入します（ Base 、またはおそらく十分にサポートされたパッケージで）。 間違いなく、これはこの目的のためにMatrix{Matrix}よりもはるかに強力で柔軟性がありますが、同様に効率的です。

これらのルールは、ユーザーが受け入れて構築するのに十分シンプルだと思います。

PS- @ StefanKarpinski実用上の理由から、再帰のブールキーワード引数は、転置のビューでは機能しません。 ビューのタイプはブール値に依存する場合があります。

また、他の場所で言及しましたが、完全を期すためにここに追加します。再帰転置ビューには、ラップしている配列と比較して要素タイプが変更される可能性があるという厄介なプロパティがあります。 例： transpose(Vector{Vector}) -> RowVector{RowVector} 。 実行時のペナルティなしで、または出力タイプを計算するために推論を呼び出すことによって、この要素タイプをRowVectorで取得する方法を考えていませんでした。 言語の観点からは、現在の振る舞い（推論を呼び出す）は望ましくないと思います。

注意：ユーザーがconjを定義して別の型を返すことを妨げるものは何もないので、 ConjArrayビューも、再帰的であるかどうかに関係なく、この問題に悩まされます。

@stevengj –「複雑な」2x2行列が、複雑なベクトル空間ではなく形式的に実数のベクトル空間であると指摘するのは理にかなっていますが、その点は、再帰的随伴の元の動機に疑問を投げかけます。 @andyferrisの提案は良くありません（非再帰的な転置と随伴）。 複雑な2x2の例とブロック行列表現の両方が再帰的に随伴作用素を「望んでいる」という事実は示唆的ですが、その最初の例についてのコメントを考えると、非再帰的随伴作用素が他にない場合はないかと思います。より正確で便利です。

随伴作用素が再帰的でない場合、それは随伴作用素ではありません。 それはただ間違っています。

少し時間があれば、それをもう少し正当化できますか？

ベクトルの随伴は、それをスカラーにマッピングする線形演算子でなければなりません。 つまり、 a'*a aがベクトルの場合、 a'*aはスカラーでなければなりません。 そして、これは、定義するプロパティがa'*A*a == (A'*a)'*aであるため、行列に対応する随伴を誘発します。

aがベクトルのベクトルである場合、これはa' == adjoint(a)が再帰的でなければならないことを意味します。

OK、私はこれに従うと思います。

再帰的な内積もあります。

julia> norm([[3,4]])
5.0

julia> dot([[3,4]], [[3,4]])
25

明らかに、「随伴」または「双数」または同様に再帰的である必要があります。

中心的な質問は、すべてのベクトルa 、 bに対してa' * b == dot(a,b)が必要かどうかということだと思います。

別の方法は、 'が必ずしも随伴作用素を返すとは限らないということです。これは、要素を転置してconjを通過させる単なる配列演算です。 これはたまたま実際の要素または複雑な要素の随伴作用素です。

線形代数の随伴作用素に特別な名前と特別な記号がある理由は1つだけです。それは、内積との関係です。 これが、「共役転置」が重要な操作であり、「行列の90度の共役回転」が重要でない理由です。 それは、ドットの製品に接続されていない場合は、「スワップの行と列とのコンジュゲートすることを単にアレイ動作」である何かを持つポイントはありません。

transposeと非共役の「ドット積」の間の同様の関係を定義できます。これは、再帰的な転置を主張します。 ただし、実際には内積ではない複雑なデータの非共役「ドット積」は、真の内積ほど頻繁には表示されません。演算子が複素数で記述されている場合、双直交関係から発生します。対称（エルミート形式ではない）形式—組み込みのJulia関数や線形代数の一般的な用語すらありませんが、任意の非数値配列の行と列を交換することは、特にブロードキャストでははるかに一般的です。 これが、 adjoint再帰的にしたまま、 transpose非再帰にすることをサポートできる理由です。

そうですか。 したがって、 '名前をadjointに変更することは、 conj ∘ transposeではないことを明確にするために、変更の一部になりますか？

再帰配列と常に混同していたのは、このコンテキストでのスカラーとは何ですか？ 私がよく知っているすべての場合において、ベクトルの要素はスカラーであると言われています。 数学者がブロックベクトル/行列構造を紙に書いた場合でも、これは、要素がおそらく実数または複素数である、より大きなベクトル/行列の省略形であることがわかります（つまり、 BlockArray ）。 スカラーは*下で乗算できると期待しており、スカラーのタイプは通常、ベクトルとデュアルの間で違いはありません。

@andyferris 、一般的なベクトル空間の場合、スカラーはベクトルに乗算できるリング（数値）です。 3 * [[1,2], [3,4]]はできますが、 [3,3] * [[1,2], [3,4]]はできません。 したがって、 Array{Array{Number}}場合でも、正しいスカラー型はNumberです。

同意しました-しかし、要素は通常（同じ）スカラーであると言われていますね？

とにかく、私が見た治療法は、リングから始まり、それらからベクトル空間を構築します。 リングは+ 、 *をサポートしますが、 adjoint 、 dotなどをサポートする必要がある処理は見たことがありません。

（申し訳ありませんが、モデル化している基礎となる数学的オブジェクトを理解しようとしています）。

それはあなたが「速記」によって何を意味するか、そしてあなたが「要素」によって何を意味するかによります。

たとえば、関数の有限サイズのベクトル、および無限次元演算子の「行列」を持つことは非常に一般的です。 たとえば、次の形式の巨視的なマクスウェル方程式を考えてみ

この場合、「要素」が3成分ベクトル場である2成分ベクトルに作用する線形演算子（カールなど）の2x2行列があります。 これらは、複素数のスカラー場上のベクトルです。 ある意味で、ベクトルの「要素」は複素数（空間内の個々のポイントにあるフィールドの個々のコンポーネント）ですが、それはかなり曖昧です。

あるいは、もっと正確に言えば、ベクトルの係数を何らかの基準で記述するために常にリングを使用することはできません（Juliaの配列の性質を考えると、根拠がないわけではありません）。

いずれにせよ、結果は依然として随伴作用素が再帰的でなければならないということですよね？ あなたが何をしているのかわかりません。

（配列のオブジェクトまたは要素はS式または抽象的な数学的オブジェクトを表す他のデータ構造である可能性があり、隣接するものは乗算されると別のオブジェクトを返す可能性があるため、絶対に根拠がないようにすることができます。たとえば、整数です。）

私は特定の点を指摘するのではなく、よりよく理解しようとしているだけです:)

確かに、上記では、随伴作用素は再帰的です。 たとえば、上記のように、 [E, H] BlockVectorを（無限に？）多くの要素が複雑なBlockVectorアプローチは実行不可能だと思います。

まあありがとう。

だから、おそらく私はこの形で私の考えを蒸留することができます：

ベクトルv場合、 length(v)がベクトル空間の次元、つまりベクトル空間の要素を（完全に）記述するために必要なスカラー係数の数を表すことを期待します。また、 v[i]はi番目のスカラー係数を返します。 今日まで、私はAbstractVectorを「抽象的なベクトル」とは考えていませんでしたが、プログラマーが知っている何らかの基礎を与えられたベクトル空間の要素の係数を保持するオブジェクトと考えていました。

シンプルで便利なメンタルモデルのように見えましたが、おそらくこれは制限が多すぎて実用的ではありません。

（編集： Vector{T}では、 Tは線形代数演算が機能するためにスカラーのように動作する必要があるため、制限があります。）

でも[3,3] * [[1,2], [3,4]]はできません

私たちはそれを修正することができます。 それが良い考えかどうかはわかりませんが、確かに機能させることができます。

それが望ましいかどうかはわかりません...この場合、 [3,3]実際にはスカラーではありません。 （私たちはすでに[3,3]' * [[1,2], [3,4]]を実行する機能を持っています-これは線形代数の意味で解釈する方法を本当に知りません）。

これは興味深いコーナーケースを示しています。 v1' * v2は内積である（したがって「スカラー」を返す）と言っているようですが、 [3,3]' * [[1,2], [3,4]] == [12, 18]です。 不自然な例だと思います。

その場合、 [3,3]はスカラーです。スカラーは基礎となるリングの要素であり、 [a,b]形式の要素をリングにする（したがってベクトル/行列を定義する）ための良い方法はたくさんあります。その上）。 それらがベクトルとして書かれているという事実、またはこのリング自体が別の基礎となるリングの上にベクトル空間を形成しているという事実は、それを変更しません。 （ベクトルを隠す可能性のある他の表記法を採用することもできます！または、まったく異なる外観にすることもできます。） @ andyferrisが取得したように、スカラーとはコンテキストによって異なります。

正式には、再帰は随伴作用素の一部ではありません。 代わりに、スカラー要素の活用は作業のその部分を行います-そして、スカラーsが行列として表される場合、 s活用には、私たちが表すために使用する行列の転置が含まれることがよくありますそれ。 ただし、常にそうであるとは限りません。スカラーのリングにユーザーが指定した構造に依存します。

随伴再帰を強制することは、MATLABタイプのアプリケーションで一般的な、実用的な妥協案としては問題ないと思います。 しかし、私にとって、それを非常に真剣に受け止めるということは、非再帰的な随伴作用素と型付きスカラー+ディスパッチを使用して、基になるリングの構造が何であれ、 conjに必要な魔法を働かせることを意味します。

その場合、[3,3]はスカラーです。スカラーは基礎となるリングの要素です。

そのようなスカラーが+ 、 *定義されたリングの要素ではないことを除いて。 *はサポートしていません; [3,3] * [3,3]はできません。

随伴再帰を強制することは、MATLABタイプのアプリケーションで一般的な、実用的な妥協案としては問題ないと思います。 しかし、私にとって、それを非常に真剣に受け止めるということは、非再帰的な随伴作用素と型付きスカラー+ディスパッチを使用して、基になるリングの構造が何であれ、 conjに必要な魔法を働かせることを意味します。

私たちが実用的な構成をしたいのであれば、これは完全に問題なく、これまで行ってきたことですが、基礎となるスカラーは完全にフラット化された配列のものであり、線形代数が定義されているようです。 。 BlockVectorとBlockMatrix （およびBlockDiagonalなど）を作成するテクノロジーがあり、完全に拡張されたアレイの効率的でフラットなビューを提供します。 「アプローチは、少なくとも実行可能でなければなりません。 私はまた、入力するだけでユーザーフレンドリーな再帰的なアプローチとして、（いくつかの余分な文字としてになると思いますが起こるBlockMatrix([A B; C D])立派読めるセマンティックと潜在的に多くのコードが何であるかと引き換えにする-私は確信してこれらのポイントは議論の余地があります）。 ただし、これらすべてを実装するのはさらに手間がかかります。

@andyferrisそうです、 *が定義されていないため、リングではありません-しかし、 *簡単に定義できるのと同じページにいると思いますが、そしてそれを行うには、リング構造を与えるさまざまな方法があります。 だから私たちは同じページにいると思います：タイピングはこれを解決するためのより拡張可能な方法です。

（スカラーについて：スカラーは必ずしも完全に平坦化された構造の要素ではありません！理由はこれです。1次元の複素ベクトル空間は複素数に対して1次元であり、実数に対して2次元です。どちらの表現もそうではありません。特別。クォータニオンは複素数に対して2次元、オクトニオンは複素数に対して2次元、複素数に対して4次元、実数に対して8次元です。しかし、オクトニオンが「8次元」であると主張する理由はありません。それらのスカラーは複素数ではない実数であると主張するよりも、これらは論理によって強制されない選択です。これは純粋に表現の問題です。線形代数はいずれの場合も同じであるため、ユーザーはこの自由を許可する必要があります。 [切り捨てられた]多多項式リング、または数値フィールドの代数的拡張を伴うこのような空間のはるかに長いチェーン。どちらも行列で活発に適用されます。ジュリアはウサギの穴をこれほど遠くまで行く必要はありませんが、 それをブロックしないように、それが存在することを覚えておく必要があります。 多分談話のトピック？ :)）

@felixrehren 、リングR上のベクトルのベクトルは、直和空間として最もよく理解されます。これは、R上のベクトル空間でもあります。ベクトル自体を「基になるリング」と呼ぶのは無意味です。リング。 その推論は[[1,2], [3,4]]に完全に当てはまります。

共役と随伴は通常、別々の概念です。 「スカラー要素の活用」がここでの作業を行うべきであると言うことは、以下に述べる特別な場合を除いて、「深刻な」の反対である私には完全に間違っているように思われます。

ディラック記法で、あるリング（たとえば複素数ℂ）上のヒルベルト空間Hにある2つの要素|u⟩と|v⟩の「2成分列ベクトル」（|u⟩、|v⟩）の場合を考えてみましょう。 「ベクトルのベクトル」。 これは、自然な内積⟨（|u⟩、|v⟩）、（|w⟩、|z⟩）⟩=⟨u|w⟩+⟨v|z⟩を持つ直和ヒルベルト空間H⊕Hです。 したがって、随伴作用素は「行ベクトル」（⟨u|⟨v|）からなる線形演算子を生成する必要があります。その要素自体は線形演算子です。随伴作用素は「再帰的」 。 これは、下層リングの共役によって誘導される同じヒルベルト空間H⊕Hの要素を生成する複素共役とはまったく異なります。

クォータニオンなどのベクトルを参照することで、問題を混乱させています。 ベクトルの「要素」も基礎となる「complexified」リングの要素である場合には、当然のことながら随伴し、これらの要素の複合体は、同じものです。 ただし、これはすべての直接製品スペースに適用できるわけではありません。

言い換えると、オブジェクトタイプは、2つの異なる情報を示す必要があります。

• スカラーリング（したがって、同じ空間の要素を生成する共役）。
• 内積（したがって、双対空間の要素を生成する随伴）。

Vector{T<:Number}場合、スカラーリングがT （または複雑化されたベクトル空間の場合はcomplex(T) ）であり、内積が通常のユークリッド積であることを示すものとして読み取る必要があります。 。

ベクトルのベクトルがある場合、それは直和ヒルベルト空間であり、リングは個々のベクトルのスカラーリングの昇格であり、内積は要素の内積の合計です。 （スカラーを昇格できない場合、または内積を合計できない場合、それはベクトル/ヒルベルト空間ではありません。）

スカラーT<:Number場合、 conj(x::T) == adjoint(x::T) 。

したがって、複素数z::Complex{T}を2x2行列m(z)::Array{T,2}で表現しようとすると、タイプはzと比較して異なるリングTと異なる内積の両方を示します。 zであるため、 conjまたはadjointいずれかが同等の結果をもたらすことを期待するべきではありません。

@felixrehrenの言っていることがわかります。 スカラーが実数の場合、オクテルニアンは8次元のベクトル空間と考えることができます。 しかし、スカラー係数がオクテルニアンである場合、すべてのオクテルニアンを表す自明な次元1の基礎があります。 これが私が言ったこと（または私が意味したこと：smile :)と異なるかどうかはわかりませんが、 AbstractVector{T1}がある場合は、異なる次元のAbstractVector{T2}と同型である可能性があります（ length ）。 ただし、 T1とT2は、どちらもJulia演算子+と*下のリングである必要があります（同型写像は+動作を保持する可能性があります）ただし、 * 、または内積または随伴作用素ではありません）。

@stevengj私はいつもBlockVectorまったく同じように直和を考えてきました。 2つの（互いに素な）不完全な塩基があります。 各基底内で、最初の基底ではc₁|X₁⟩+c₂|X₂⟩、2番目の基底ではc₃|Y₁⟩+c₄|Y₂⟩のような重ね合わせを形成できる場合があります。 「直和」は、（c₁|X₁⟩+c₂|X₂⟩）+（c₃|Y₁⟩+c₄|Y₂⟩）のような状態の空間を表します。 これを複素数の次元4の基底から分離する唯一の特別なこと（つまり、c₁|X₁⟩+c²|X₂⟩+c₃|Y₁⟩+c₄|Y₂⟩のような状態）は括弧です-私には、それは表記のようです。 直和は、これらを紙に書いたり、コンピューターの配列を使って書いたりするのに便利な方法です（たとえば、対称性をカタログ化して利用したり、問題を分割したり（おそらく並列化する）などに役立つ場合があります）。 ）。 この例では、X⊕Yは依然としてスカラーが複素数である4次元のベクトル空間です。

これが、 eltype(v) == Vector{Complex{...}}とlength(v) == 2ではなくeltype(v) == Complex{...}とlength(v) == 4欲しい理由です。 これは、基になるリングとベクトル空間を確認して推論するのに役立ちます。 随伴作用素を計算するために「グローバル」転置と要素ごとのconjを実行できるのも、この「フラット化された」空間ではありませんか？

（私が1つだけ書いている間に2つの投稿がありました、 @ stevengj ：smile :)

もちろん、 BlockArrayではなく、（現在のように）直和の規則としてネストされた配列を使用する場合は、これも優れた一貫性があります。 スカラー場（一種の再帰的eltype）と、有効な平坦化された次元（一種の再帰的サイズ）を決定するためのいくつかの追加関数を利用して、実行している線形代数について少し簡単に推論できるようにすることができます。

明確にするために、私は両方のアプローチに満足しており、この議論から多くのことを学びました。 ありがとう。

@ andyferris 、2つの空間が同型であるからといって、それらが「同じ」空間であるとは限りません。どちらが「本当に」ベクトル空間であるか（または「本当に」同じかどうか）について議論することは形而上学的な泥沼です。そこから逃げることはありません。 （しかし、無限次元のベクトル空間の直和の場合は、「一方のすべての要素の後に他方のすべての要素が続く」という直和の「平坦化された」概念の制限を示しています。）

繰り返しますが、私はあなたのポイントが何であるかわかりません。 Juliaのeltype(::Vector{Vector{Complex}})をComplexにすること、またはlengthが長さの合計を返すことを真剣に提案していますか？ ジュリアの誰もが直和空間にあなたの「平坦化された」同型を採用することを強制されるべきだと？ そうでない場合、随伴作用素は再帰的でなければなりません。

また、「特定の点を指摘するのではなく、よりよく理解しようとしている」場合は、別のフォーラムに持ち込むことができますか？ この問題は、直和空間の意味について形而上学的な議論がなければ十分に混乱します。

2つのスペースが同型であるからといって、それらが「同じ」スペースであるとは限りません。

私は絶対にそれを示唆していませんでした。

繰り返しますが、私はあなたのポイントが何であるかわかりません

AbstractArrayで線形代数を実行したい場合は、 eltype方がリングであることが真剣に提案されています（ + 、 * 、およびconjサポート） [1,2] * [3,4]が機能しないため、たとえばVector eltypeを除外します。 そして、ベクトルのlengthは、実際には線形代数の次元を表します。 はい、これは無限次元のベクトル空間を除外しますが、一般的にJuliaではAbstractVectorを無限のサイズにすることはできません。 これにより、Juliaで線形代数機能を実装および使用する方法について推論しやすくなると思います。 ただし、ユーザーは、ネストされた配列構造を使用するのではなく、 BlockArrayなどを介して直接合計を明示的に示す必要があります。

これは非常に画期的な提案であり、顕著な欠点があります（あなたが言及したものもあります）ので、「それはいい考えですが、実用的ではない」と言っても不幸になることはありません。 ただし、ネストされた配列アプローチでは、基礎となる線形代数に関するいくつかのことが少し不透明になることも指摘しようとしています。

これはすべて、OPに直接関連しているようです。 強制的な平坦化アプローチでは、再帰的転置/随伴を破棄します。再帰的転置/随伴を破棄した場合、線形代数では平坦化された構造のみが実行可能になります。 平坦化されたアプローチを強制しない場合は、再帰的な随伴作用素を維持する必要があります。 私には、それは関連した決定であるように思われました。

Juliaのeltype(::Vector{Vector{Complex}})をComplexにすること、またはlengthが長さの合計を返すことを真剣に提案していますか？

いいえ、申し訳ありませんが、私が書いた内容が明確ではなかった可能性があります。特定の状況では、この目的のための2つの新しい便利な機能が役立つ可能性があることを示唆しただけです。 たとえば、そのリングのzeroまたはoneが必要な場合があります。

ジュリアの誰もが直和空間にあなたの「平坦化された」同型を採用することを強制されるべきだと言っていますか？

可能性として、そうだと提案していました。 私はそれが最善のアイデアであると100％確信しているわけではありませんが、いくつかの利点（およびいくつかの欠点）があると感じています。

ここで実行可能な変更の領域に戻ると、 @ stevengjの提案の簡略化されたバージョンが、ここに進む方法のようです。

• conjそのまま（要素ごとに）保持します。
• a'をadjoint(a)に対応させ、常に再帰的にします（したがって、要素に随伴が定義されていない文字列の配列などでは失敗します）。
• a.'をtranspose(a)に対応させ、再帰的ではないようにし（ permutedims ）、要素のタイプを無視します。

これから抽出できる主な実際の「todo」は次のとおりです。

1. [] ctranspose名前をadjointます。
2. [] transposeを非再帰的に変更します。
3. []これが行ベクトルにどのように適合するかを理解します。

再帰的転置に依存することは十分にまれであるため、これを1.0で変更して、NEWSで壊れているとリストすることができると思います。 ctransposeをadjointに変更すると、通常の非推奨になる可能性があります（ただし、1.0ではこれを行います）。 他にやらなければならないことはありますか？

@StefanKarpinski 、対応する変更をRowVectorに加える必要もあります。 1つの可能性は、 RowVectorをTranspose Adjointタイプとtransposeとレイジー再帰adjointをそれぞれ使用することです。そしてConj （怠惰なconj ）を取り除くために。

少なくとも接線方向に関連するいくつかの変更

• 以下のためのいくつかのビュータイプtransposeとadjointのAbstractMatrix
• adjoint(::Diagonal)再帰的にします（おそらく、Juliav0.6.0より前のtransposeとctranspose Diagonalでこの「バグ」を修正する必要があります）
• 次のような適切な「スカラー」タイプを使用します。 v = Vector{Vector{Float64}}(); dot(v,v) （現在はエラー- zero(Vector{Float64})を返そうとします）

OK、私は再帰的な区分行列をより真剣に受け止めようとしており、これをバックアップするために、ここでDiagonalの動作も改善しようとしています（ブロック対角を予測するいくつかの方法がすでにあります） getindexなどの構造なので、この場合は転置を再帰的にするのが自然なようです）。

私が行き詰まり、上記のすべての議論のポイントを直接動機付けたのは、 inv 、 det 、 expmを含むそのような構造で線形代数演算を行う方法です。 eigなど。 たとえば、すべての対角要素の積をとるdet(::Diagonal{T}) where Tメソッドがあります。 T <: Numberで見事に機能し、すべての要素が同じサイズの正方行列ます。 （彼らは同じサイズの正方行列である場合はもちろん、その後の要素が環を形成し、そしてそれはすべての非常に賢明だ-また、再帰転置（編集：随伴）が正しいものです）。

ただし、一般的なブロック対角行列Diagonal{Matrix{T}} 、または任意のブロック行列Matrix{Matrix{T}}を考えると、その行列式は一般にスカラーTと言えます。 つまり、サイズが(3 ⊕ 4) × (3 ⊕ 4) （3×3、4×4の次元の行列であり、一致する非対角要素である対角要素を持つ2×2行列）の場合、 detは「平坦化された」7×7構造の行列式ですか、それとも単に2×2の要素をそのまま乗算する必要がありますか（この場合はエラーアウト）？

（編集：上記のディメンションをすべて異なるものに変更しました。これにより、あいまいな言語を避けることができます）

a'が再帰的であることに問題はありませんが、個人的には、新しいa.'表記が非常に混乱していることに気付くでしょう。 構文a.'を見せてくれたら、ジュリアのメンタルモデルに基づいて、 transpose.(a)つまりa要素ごとの転置を実行すると言います。違う。 または、 a'とa.'両方が転置のオプションであり、そのうちの1つも要素ごとに再帰することを示した場合、 a.'は要素ごとの再帰、そして私は再び間違っているでしょう。

もちろん、この場合、 .が何を意味するかについての私のメンタルモデルは間違っています。 しかし、その構文をまったく間違った方法で解釈するのは私だけではないと思います。 そのためには、非再帰的な転置に.'以外のものを使用することをお勧めします。

@rdeitsこの構文はMATLABから派生していると思います。 （非常に素晴らしい）ドットコールブロードキャスト構文がv0.5に導入されると、これは少し不幸になりました。

MATLABとは別に独自のパスを作成し、これを変更することもできますが、それについては別の議論があったと思います（誰もがどこを覚えていますか？）。

ああ、それは残念です。 ありがとう！

別のやること：

• [] issymmetricとishermitianを修正して、 issymmetric transposeとadjointに一致させます。各ペアの前者は非再帰的で、後者は再帰的です。

Matlabの.'構文は、新しい.構文のコンテキストでは間違いなく非常に残念です。 これを変更することに反対するつもりはありませんが、転置のための新しい構文が必要であり、使用できる構文があるかどうかはわかりません。 転置の提案はありますか？

転置構文の説明をここに移動しましょう： https ：

transpose / ctranspose / adjointが再帰的であるという強い意見はありませんが、 A::Matrix{Matrix{T}}をブロック行列のように扱いたくありません。怠惰なhvcat感覚。これは、 @ andyferrisが少なくとも部分的に暗示しているようです。 つまり、 Aの要素がすべて同じサイズの正方行列である場合（つまり、リングを形成する場合）、 det(A)はそのサイズの正方形を再び返すと予想されます。 長方形またはサイズが異なる場合は、エラーが発生する可能性があります。

とは言うものの、ブロック行列/怠惰な猫のタイプは便利かもしれませんが、それはずっと行き渡り、フラット化されたデータを処理するためにたとえばgetindexも定義する必要があります。 しかし、私はこの概念がMatrixやDiagonalような他の既存のマトリックスタイプに吸収されることを絶対に望んでいません。

@martinholters、これは安心です。 このスレッドの前半で私がパニックに陥ったのは、Juliaの線形代数フレームワーク全体を任意のブロック行列（部分行列のサイズが異なる）のMatrix{Matrix}に適用できるはずだという考えでした。

私が「平坦化」で主張していたのは、要素が何であるかについての派手な内省を行うことではなく、単に要素自体のメリットをリングの要素として扱うことです。 ただし、再帰的なctranspose / adjointはこれを拡張して、線形演算子のように機能する要素を許可します。これは正しくて便利なようです。 （他の場合は、ベクトルのように機能するベクトルの要素であり、再帰的随伴も正しいです）。

もう少し戻ると、 transpose(x) = xとctranpsose(x) = conj(x)デフォルトのno-op動作を削除する元の動機は何でしたか？ これらはいつも私にとって非常に便利に思えました。

もう少し戻ると、transpose（x）= xおよびctranpsose（x）= conj（x）のデフォルトのno-op動作を削除する元の動機は何でしたか？ これらはいつも私にとって非常に便利に思えました。

これは、 ctransposeを特殊化できなかったカスタム線形演算子タイプ（AbstractArrayのサブタイプにすることはできません）によって動機付けられました。 これは、フォールバックから誤ったno-op動作を継承したことを意味します。 フォールバックが黙って間違ってしまうことがないようにディスパッチを構成しようとしました（ただし、悲観的な複雑さがある可能性があります）。 https://github.com/JuliaLang/julia/issues/13171

https://discourse.julialang.org/t/proposal-rename-rowvector-to-transposevector-add-rowvector-that-doesnt-transposes-entries/4681

2つのオプションがあるようです。どちらの場合も、 transposeは非再帰的になります。それ以外の場合は、次のようになります。

1. 非再帰的なctranspose 。
2. 再帰ctranspose 。

@ stevengj 、 @ jiahao 、 @ andreasnoack –ここでのあなたの好みは何ですか？ その他？

@jiahaoのJuliaCon2017の講演以来、私はこれについて多くのことを考えてきました。

私には、線形代数を要素タイプTとして「スカラー」フィールドに関して定義する必要があると今でも感じています。 Tがフィールドの場合（ + 、 * 、およびconj （ - 、 / 、..もサポート） 。）） Base.LinAlgメソッドが失敗する理由がわかりません。

OTOHたとえば、ブロック行列の転置について話すことは非常に一般的（そして有効）です。 ここで「数学」型理論から学ぶことができると思います。たとえば、「1次」のスカラーのセット、「2次」のスカラーのセット、「3次」を使用して、セットのセットについて議論することから生じる奇妙なステートメントを処理しようとします。スカラーのセットのセットの「順序」セットなど。 配列の配列を扱う場合、ここでも同じ問題（および機会）があると思います。Juliaの型システムを使用して、「真の」スカラーの「1次」配列、スカラーの配列の「2次」配列などを記述することができる可能性があります。 。 @ stevengj 、私、および他の人の間の長い議論は、はい、任意の「順序」の配列に対して自己矛盾のない一連の操作を思い付くことができるという事実から生じたと思います。このフレームワークでは（c）転置は明確かつ正確に再帰的ですが、それを行う必要はありません。 Jiahaoの話が明確に指摘しているように、プログラミング言語/フレームワークは、スカラーを配列から区別する（またはしない）、ベクトルを行列から区別する（またはしない）などについて意味的な選択を行います。これは私たちが行うことができる関連する選択だと思います。

私にとって、ここで重要な点は、「任意の順序」の配列を機能させるには、通常はベクトルと行列でのみ定義されるいくつかの操作を「スカラー」に教える必要があるということです。 これを行う現在のJuliaメソッドはtranspose(x::Number) = xです。 ただし、このメソッドを削除することで、配列とスカラーの意味上の区別を拡張したいのですが、それはかなり実現可能かもしれないと思います。

次のステップは、1次行列と2次行列の違いなどをBase.LinAlgに教えることです。 私は2つの実行可能なオプションを考えました、もっとあるかもしれません、私は本当に知りません：

• だから、オプトイン特色"arrayness"へのいくつかの並べ替えを持っているtranspose(::AbstractMatrix{T})時に再帰的であるTあるAbstractMatOrVecときではなく、 TありますNumber 、それ以外の場合は何らかの方法で構成可能（オプトイン、オプトアウトなど）にします。 （いくつかの点で、これは要素のtransposeメソッドの動作を制御することによって行われていましたが、現在は（outer）のtransposeメソッドの動作を制御する方がクリーンだと思います。 ）配列）。
• または、 Arrayを含むほとんどのAbstractArrayが1次であり（要素はスカラーフィールドである）、別のAbstractArrayタイプ（たとえばNestedArray ）を使用することを表明します。 ）配列をラップし、それらの要素がスカラーではなく配列として扱われることを「マーク」します。 これを少し試してみましたが、上記のオプションの方がユーザーの負担が少ないようです。

Juliaは配列とスカラーを強力にセマンティックに分離しているように感じます。また、スカラーは配列プロパティtransposeについて「教えられる」必要があるため、現在の状況は（私には）少し矛盾しているように見えます。 ユーザーは、 Matrix{Float64}がスカラーの行列（1次配列）であり、 Matrix{Matrix{Float64}}がブロック行列（2次配列）であることを明確に理解できます。 型システムまたは特性を使用して、配列が「一次」であるかどうかを判断する方が一貫している場合があります。 また、最初にリストしたオプションを使用すると、Juliaがよりユーザーフレンドリーになり（ ["abc", "def"].'を実行できます）、ブロック行列を使用して実用的で便利なデフォルトの処理を実行できる柔軟性が維持されると思います。

長い間ハープして申し訳ありませんが、 JuliaConで@jiahaoと話した後、ここでもう少しうまくやれると感じました。 @StefanKarpinskiが上記で言及した他のオプションを「機能」させることができると確信していますが、 RowVectorが導入される前は、行列/ベクトル代数が「機能」していたのと同じように「機能」します。

TLDRは-（ c ） transpose再帰的にするかしないか-両方を実行させます（つまり、構成可能にします）。

これらは良い点ですが、 (c)transposeが再帰的であるという苦情のほとんどすべて（すべてではないにしても）は、 'と.'非数学的な使用に関連していることを指摘したいと思います。 Vector{String}とVector{PyObject}を1xn行列に再形成する場合。 タイプごとに修正するのは簡単ですが、面倒であることがわかります。 ただし、再帰的定義は数学的に正しいものであり、「便利だがまれな場合は間違っている」よりも「正しいが多くの場合は煩わしい」の方が優れていると考えられていました。

考えられる解決策は、最初の箇条書きでの提案です。つまり、配列のような要素に対して再帰的な転置を行うことだけです。 T<:AbstractVecOrMatは、ステータスを「便利だが非常にまれなケースでは間違っている」に変更するほとんどのケースをカバーすると思います。 それでも間違っている可能性がある理由は、 AbstractArrayインターフェイスが主に配列（ getindex ）セマンティクスに関するものであるため、一部の演算子のような型がAbstractMatrixカテゴリに適合しないためです。 、線形代数ではありません。

@andyferris 、スカラーの随伴および双対は完全に明確に定義されており、 ctranspose(x::Number) = conj(x)は正しいです。

私の感じでは、 transposeほとんどの使用法は「数学的ではない」ものであり、 ctransposeほとんどの使用法（つまり、活用行動が望まれる場所での使用）はマシーです（活用する理由が他にないため） ）。 したがって、私は非再帰的なtransposeと再帰的なctransposeを好む傾向があります。

個人的には、ネストされたArraysとしてブロック配列を見ようとすると、ここでの理由により複雑になると思います。https：//github.com/KristofferC/BlockArrays.jlの専用タイプを使用する方がよいでしょう

@KristofferC、よさそうだ。

@stevengjが上で述べた非常に有効な点が1つあります。それは、要素が数学的な意味でのベクトルや線形演算子である場合がありますが、 AbstractArrayではない場合があるということです。 これらに対して再帰的な（c）移調を行う方法が絶対に必要です-これについて考えたかどうかはわかりませんが、私はそれについて言及したいと思いました。

このトピックに関するslack /＃linalg会話のハイライト。 上記のスレッドの一部を要約します。 セマンティクスに焦点を当て、スペルを回避します。 （その会話に参加したすべての人に感謝します！:)）

3つの意味的に異なる操作が存在します。
1）「数学的随伴作用素」（再帰的で怠惰な）
2）「数学的な転置」（理想的には再帰的で怠惰な）
3）「構造的転置」（理想的には非再帰的で「熱心」）

現在の状況：2次元C場合、「数学的な随伴」はctranspose 、「数学的な転置」はtransposeに、「構造的な転置」はpermutedims(C, (2, 1))にマップされます。そしてreshape(C, 1, length(C))一dimesionalのためのC 。 問題：「構造的転置」は一般的な操作であり、 permutedims / reshape話は、実際にはやや混乱/不自然/迷惑です。

それがどのように発生したか：以前は、「構造転置」は、 transpose(x::Any) = x 、 ctranspose(x::Any) = conj(x) 、 conj(x::Any) = xなどの一般的なno-opフォールバックを介して「数学随伴」/「数学転置」と混同されていました。 これらのフォールバックにより、ほとんどの場合、 [c]transposeと関連する接尾辞演算子' / .'が「構造転置」に使用されます。 すごい。 しかし、それらのタイプの[c]transpose特殊化の定義がない場合、一部のユーザー定義の数値タイプで[c]transposeを含む操作がサイレントに失敗する（誤った結果を返す）こともありました。 痛い。 したがって、これらの一般的なno-opフォールバックは削除され、現在の状況が得られました。

問題は今何をすべきかです。

理想的な結果：「構造的転置」のための統一された、自然でコンパクトな呪文を提供します。 意味的に正しい数学的随伴と転置を同時にサポートします。 使用中または実装時にトリッキーなコーナーケースを導入することは避けてください。

2つの広い提案が存在します：

（1）数学的随伴、数学的転置、および構造的転置を、構文的および意味的に異なる3つの演算として提供します。 利点：すべてが機能し、概念が明確に分離され、トリッキーなコーナーケースが回避されます。 欠点：説明および実装する3つの操作。

（2）3つの操作を2つにシューホーンします。 この提案には3つの形式があります。

（2a） transpose意味的に「構造的転置」にし、一般的な場合には「数学的転置」としても機能します。 利点：2つの操作。 明確なスカラー要素を持つコンテナーで期待どおりに機能します。 欠点：「数学的な転置」セマンティクスを期待する人は誰でも、明確にスカラー要素を持つコンテナーよりも複雑なオブジェクトで誤った結果をサイレントに受け取ります。 ユーザーがその問題を見つけた場合、「数学的な転置」セマンティクスを実現するには、新しいタイプやメソッドを定義する必要があります。

（2b）タイプの「マシネス」を示す特性を導入します。 オブジェクトに随伴/転置を適用するときに、コンテナ/要素のタイプが「数学」である場合は、再帰します。 そうでない場合は、再帰しないでください。 利点：2つの操作。 さまざまな一般的なケースをカバーできます。 欠点：一般的なno-op [c]transposeフォールバックと同じ問題が発生します。つまり、必要な特性定義がないユーザー定義の数値タイプに対して、サイレントに誤った結果が生じる可能性があります。 「数学」タイプへの構造的転置または「非数学」タイプへの数学的転置の適用を有効にしません。 すべての場合において、オブジェクトが「数学的」であるかどうかを判断する方法が明確ではありません。 （たとえば、要素タイプが抽象である場合はどうなりますか？再帰的/非再帰的決定は、実行時と要素ごと、または実行時であり、集合タイプをチェックするためにコンテナー内のすべての要素に対して最初のスイープが必要ですか？）

（2c） adjoint （ ctranspose ）「数学随伴」とtranspose 「数学転置」を維持し、 adjoint特化した（一般的なフォールバックではない）メソッドを導入します/非数値スカラー型の場合はtranspose （例： adjoint(s::AbstractString) = s ）。 利点：2つの操作。 正しい数学的セマンティクス。 欠点：非数値型にはadjoint / transpose断片的な定義が必要であり、ジェネリックプログラミングが妨げられます。 「数学」タイプへの構造転置の適用を有効にしません。

提案（1）および（2a）は、（2b）および（2c）よりも大幅に幅広い支持を得ました。

詳細については、＃19344、＃21037、＃13171、およびslack /＃linalgを参照してください。 ベスト！

素敵な記事をありがとう！

オプション1に適した別の可能性をテーブルに置きたいと思います。数学行列と表形式データ用に異なるコンテナータイプを用意します。 その後の意味A'の種類によって決定される可能性がA （注：上述のようにではない、その要素型）。 ここでの短所は、これには2つの間に多くのconvertが必要になる可能性があり（そうなるでしょうか？）、もちろん、非常に混乱を招く可能性があるということです。 確かに、私は利益がこの混乱を正当化するかどうかについて懐疑的ですが、それでもそれについて言及したいと思いました。

おかげで、素晴らしい記事。 （1）に投票します。

素晴らしい記事。 （1）の場合、スペルは次のようになることに注意してください。

• 随伴作用素： a' （再帰的、怠惰な）
• 数学的転置： conj(a') （再帰的、怠惰な）
• 構造転置： a.' （非再帰的、熱心）

したがって、必ずしも新しい演算子を導入する必要はありません。数学的な転置は、随伴と共役の（怠惰で効率的な）構成にすぎません。 最大の問題は、2つの類似した演算子、つまり接尾辞'と.' 、意味的にまったく異なるものになることです。 ただし、最も正しいジェネリックコードでは、誰かが'または.'を使用したかどうかは、「このことの随伴作用素をくれ」または「スワップ」を意味するかどうかの99％正確な指標であると思います。このことの寸法」。 さらに、誰かが' 、実際に「このことの次元を交換する」ことを意味する場合、そのコードは、スカラー随伴が自明でない要素（複素数など）を持つ行列に対してすでに正しくありません。 誰かが実際に「これの随伴の共役を私に与えてください」を意味した残りのいくつかのケースでは、実際には人々が実際にa.'を使用するので、 conj(a')を書くとその意味がはるかに明確になると主張します「 aの寸法を入れ替える」という意味です。

これに必要なすべての基礎となるジェネリック型を解明することは@ andyferrisと@andreasnoackはすでにこの問題についていくつかの考えを持っており、可能であるように思われます。

この議論は他の場所で行われたので、私も更新する必要があると思いました。 この提案について、私が完全に見逃していた（明らかな？）こ​​とが1つあったことを認めます。それは、線形代数に.'を引き続き使用すると想定したことですが、そうではないことを認識しておく必要があります。 ！

たとえば、 vector.'はRowVectorである必要はなくなります（ RowVectorは線形代数の概念であるため、「双対」ベクトルでの最初の試みです）。 Matrixます。 線形代数で「非共役転置」が必要な場合、実際に行っているのはconj(adjoint(a))を使用することです。これを使用し、すべての線形代数ユーザーに使用することをお勧めします（これまではただ、使用するMATLAB以来、長年の「悪い」習慣だったa.'ではなくa'私は本当のことを知っていた任意の行列（またはベクトル）を転置のため、私が本当に望んときだったadjoint （またはデュアル）-名前の変更はここで大きな助けになります）。

また、これにより興味深い空間が開かれることも簡単に指摘しておきます。 以前は、 vector'とvector.'は、「データ転置」を実行し、デュアルベクトルのようなものを取得するという二重のニーズを満たす必要がありました。 .'は配列サイズを操作するためのものであり、 'は線形代数の概念であるため、 RowVectorを1D DualVectorなどに変更できる可能性があります。完全に。 （おそらく、ここでこれについて議論するべきではありません-誰かがこれに食欲を持っているなら、別の問題を作りましょう。）

最後に、提案されたアクションプランをSlackからコピーします。

1） transposeをLinAlgからBaseに移動し、 RowVector作成されなくなったり、再帰的でなくなったりすることについての警告（0.7のみ）を追加します（可能な場合）
2）どこでもctranspose名前をadjointます
3） Vector 、 ConjVector 、 RowVectorが'とconjと*組み合わせで機能することを確認します。 RowVector名前を変更します。 （ここでもconj(vector)怠惰にします）。
4） conjおよびConjMatrixともうまく相互作用する怠惰な行列随伴作用素を導入する
5） A_mul_Bcなどを削除します。 A_mul_B!名前をmul! （または*! ）に変更します。
6）利益

@stevengjは書いた：

@andyferris 、スカラーの随伴および双対は完全に明確に定義されており、 ctranspose(x::Number) = conj(x)は正しいです。

記録のために、私は間違いなくこれに同意します。

私の感じでは、転置のほとんどの使用法は「非数学的」であり、ctranspose（...）のほとんどの使用法は数学的です

したがって、アイデアはこれを形式化することです。 transposeすべての使用は「非数学」になり、 adjointの唯一の使用は「数学」になります。

たとえば、 vector.'はRowVectorである必要はなくなります（ RowVectorは線形代数の概念であるため、「双対」ベクトルでの最初の試みです）。 Matrixます。

ただし、 .'を怠惰にしたいのです。 たとえば、 X .= f.(x, y.')はまだ割り当てられていないはずです。

ここに質問があります： issymmetric(::AbstractMatrix{<:AbstractMatrix})をどのように実装する必要がありますか？ transposeと一致するのは、非再帰的なチェックでしょうか？ 私は実装を見ています。 要素がtransposeできることを前提としています。 OTOH issymmetric(::Matrix{String})かどうかを確認することは非常に有効なようです...

Symmetric btwでラップされている場合、現在は再帰的ではありません

julia> A = [rand(2, 2) for i in 1:2, j in 1:2]; A[1, 2] = A[2, 1]; As = Symmetric(A);

julia> issymmetric(A)
false

julia> issymmetric(As)
true

julia> A == As
true

はい、私はこのためのPRの作成に取り組んでおり、この種の矛盾がたくさんあります。 （配列コードでtranspose 、 adjoint 、 conjすべてのインスタンスを検索しているときに、少し前にその問題に遭遇しました）。

特に指示がない限り、 issymmetric(a) == (a == a.')およびishermitian(a) == (a == a')ような動作を実装します。 これらはそれ自体かなり直感的に見え、AFAICTの既存のissymmetric使用法は、 Number要素タイプ用です（または、ネストされた配列にはあまり意味をなさない他の間違い/仮定が頻繁にあります） 。

（代替の実装はissymmetric(a) == (a == conj(adjoint(a)))です...「きれい」ではなく、「データ」配列（ Stringなど）では機能しませんが、 Number配列では一致します

特に指示がない限り、 issymmetric(a) == (a == a.')およびishermitian(a) == (a == a')ような動作を実装します

私にとって正しい解決策のようです。

更新：気が変わった。 対称はおそらく主に線形代数用です

ほんの小さな提案です。2つのベクトル（ dotu ）の積に対して合計を行うと便利なことがよくあり、スカラーを返すx.’yはこれを行うための便利な方法です。 だから私はtranspose(::Vector)からMatrixを返さないことに賛成です

はい、 RowVectorなるので、スカラーを取得する必要があります。 （転置は再帰的ではないことに注意してください）。

おそらく接線のコメントで申し訳ありませんが、このスレッドの多くの人々は「ベクトル空間のスカラーのリング」について話し続けています。 定義上、ベクトル空間のスカラーは、リングだけでなく、フィールドを形成する必要があります。 ベクトル空間に非常に似ているが、スカラーがフィールドではなくリングを形成するだけの代数的構造は「モジュール」と呼ばれますが、モジュールは少し難解すぎてBase ... erで処理できないと思います。 ..モジュール。

整数配列をサポートしているため、ベクトル空間だけでなくモジュールも効果的にサポートしています。 もちろん、整数配列を浮動小数点配列に埋め込まれたものとして動作的に表示することもできるため、それらはベクトル空間の部分的な表現です。 ただし、モジュラー整数の配列を作成することもできます（たとえば）。非素数係数を使用すると、どのフィールドにも自然に埋め込まれていないリングを操作できます。 要するに、私たちは実際にはベクトル空間だけでなく一般的なモジュールを検討したいのですが、私たちの目的には大きな違いはないと思います（一般的には+と*についてのみ話します）

はい、ジュリアは確かに、一般的なモジュールと真のベクトル空間での代数演算をサポートしています（そしてサポートする必要があります）。 しかし、私が理解しているように、コミュニティの一般的な哲学は、 Base関数は、「「通常の」一般的な線形代数ルーチン」を念頭に置いて設計する必要があるというものです。たとえば、整数行列の正確な線形代数計算では、 Base属していないので、基本的な設計上の決定を行うときは、スカラーがフィールドを形成すると想定する必要があります。 （あなたが言ったように、実際には、それは実際には重要ではありません。）

クロスポストhttps://github.com/JuliaLang/julia/pull/23424#issuecomment-346678279

このプルリクエストが表す＃5332と＃20978を前進させる努力に感謝し、関連する計画のほとんどに参加しています。 また、このプルリクエストが進める用語の選択とダウンストリームへの影響についても参加したいと思います。そのため、これらの選択によって利用可能な最良のトレードオフが得られることを定期的に確信してください。

その立場を自分に納得させようとするたびに、私は同じ一連の不安に座礁します。 これらの不安の1つは、この選択がLinAlg強い実装の複雑さです。転置と配列反転を圧縮すると、 LinAlgが両方を処理するようになり、 LinAlgがはるかに大きなセットをサポートする必要があります。一般的な操作での型の組み合わせ。

説明のために、 mul(A, B)考えてみましょう。ここで、 AとBは、裸、随伴ラップ、転置ラップ、または配列フリップラップされたMatrixです。 転置と配列反転を混同しない限り、 Aは、 Matrix 、随伴でラップされたMatrix 、または転置でラップされたMatrix （および同様にB ）。 したがって、 mul(A, B)は9つのタイプの組み合わせをサポートする必要があります。 しかし、転置と配列フリップを混同すると、 Aは、 Matrix 、随伴ラップされたMatrix 、転置ラップされたMatrix 、または配列になる可能性があります-フリップラップされたMatrix （および同様にB ）。 したがって、 mul(A, B)は16種類の組み合わせをサポートする必要があります。

この問題は、引数の数とともに指数関数的に悪化します。 たとえば、コンフィレーションがない場合、 mul!(C, A, B)は27のタイプの組み合わせをサポートする必要がありますが、コンフィレーションがある場合、 mul!(C, A, B)は64のタイプの組み合わせをサポートする必要があります。 そしてもちろん、 Vectorと非Matrix行列/演算子タイプをミックスに追加すると、事態はさらに複雑になります。

この副作用は、この変更を進める前に検討する価値があるようです。 ベスト！

この投稿では、github、slack、triageに関する最近の議論を統合/レビューし、今後の可能性のあるパスを分析します。 （https://github.com/JuliaLang/julia/issues/20978#issuecomment-315902532の精神的な後継者は、1.0に到達する方法について考えることから生まれました。）

3つの意味的に異なる操作が問題になっています：

• 随伴（線形代数、再帰的、理想的にはデフォルトで怠惰）
• 転置（線形代数、再帰、デフォルトでは理想的には怠惰）
• array-flip（abstract-array-ic、non-recursive、理想的にはデフォルトで「lazy」）

マスターでのこれらの操作のステータス

• 随伴作用素はadjoint / 'と呼ばれます（ただし、 '除いて熱心です-特別にA[c|t]_(mul|rdiv|ldiv)_B[c|t][!]呼び出しに下げられた式を含み、中間の熱心な随伴作用素/転置を回避します） 。

• 転置はtranspose / .'と呼ばれます（ adjointと同じ注意が必要です）。

• 配列フリップは、2次元のCはpermutedims(C, (2, 1))と呼ばれ、1次元のC reshape(C, 1, length(C))と呼ばれます。

関連する問題

1. 5332： A[c|t]_(mul|rdiv|ldiv)_B[c|t]への特別な値下げと、それに関連するメソッド名の組み合わせコレクションは、1.0までに消えるはずです。 その特別な下降/関連するメソッド名を削除するには、怠惰な随伴と転置が必要です。

2. 13171：随伴（née ctranspose ）と転置は、以前はtranspose(x::Any) = x 、 ctranspose(x::Any) = conj(x) 、 conj(x::Any) = xなどの一般的なno-opフォールバックを介して配列フリップと混同されていました。 これらのフォールバックにより、一部のユーザー定義の数値タイプで[c]transposeを含む操作は、それらのタイプの[c]transpose特殊化がないと、サイレントに失敗します（誤った結果を返します）。 間違った結果を黙って返すのは悪いニュースなので、それらのフォールバックは削除されました（＃17075）。 より多くのサイレント障害を導入しないことは素晴らしいことです。

3. 17075、＃17374、＃19205：先行するフォールバックを削除すると、配列フリップの利便性が低下しました。 そして、（謝罪、私のせいで）関連する非推奨の警告と相まって、その削除は（一時的に？）苦情を引き起こしました。 配列フリップのより便利な呪文がいいでしょう。

4. 21037：1.0の今や混乱している.'構文を削除するといいでしょう。 この変更を有効にするには、上記の特別な下降を削除する必要があります。

これらの問題を解決するための設計目標

特別な下降および関連するメソッド名を削除し、サイレントエラーの発生を回避し、転置および配列フリップに直感的で便利な呪文を提供し、 .'を削除します。 最小限の追加の複雑さと破損で前述のことを達成します。

デザイン提案

この分野は、2つの設計提案に絞り込まれています。

1. 随伴作用素adjoint呼び出し、 conjadjoint （「随伴作用素」）を転置し、 transposeを配列反転します。 adjointとconjadjointはLinAlgに住んでおり、 transposeはBase住んでいます。

2. 随伴adjoint呼び出し、 transpose転置し、 flipを配列反転します。 adjointとtransposeはLinAlgに住んでおり、 flipはBase住んでいます。

一見すると、これらの提案は表面的にしか異なっていないように見えます。 しかし、さらに調査すると、実際的な違いが明らかになります。 これらの命名スキームの相対的な表面的なメリットについての議論を避けて、それらの深い実際的な違いを見てみましょう。

違い、高レベルのビュー

1. 複雑：

   提案1は、array-flip transpose呼び出すことにより、転置と随伴に加えて、 LinAlgにarray-flipの処理を強制します。 したがって、 LinAlgは、一般的な操作でサポートされる型の組み合わせのセットを大幅に拡張する必要があります。 https://github.com/JuliaLang/julia/pull/23424#issuecomment -346678279は、例としてこの追加の複雑さを示しています。以下の説明では、追加の複雑さの存在を暗黙的に確認しています。

   提案2が必要ですLinAlg唯一の転置サポートおよび随伴、 LinAlg今ありませんが。

2. 破損：

   提案1は、既存の操作の基本的なセマンティクスを変更します。 transposeは転置ではなく配列フリップになり、それに応じてすべてのtranspose関連の機能を変更する必要があります。 （たとえば、 transposeという名前に関連付けられたLinAlgすべての乗算および左/右除算演算では、セマンティックの修正が必要になります。）この変更の実現方法によっては、この変更によりサイレント破損が発生します。現在のセマンティクスが依存している場合はいつでも（意図的または不注意に）。

   提案2は、既存のすべての操作の基本的なセマンティクスを保持しています。

3. カップリング：

   提案1は、線形代数の概念（転置）をBaseに、抽象配列の概念（array-flip）をLinAlgに持ち込み、 BaseとLinAlg強力に結合します。

   提案2は、抽象的な配列と線形代数を明確に分離し、前者はベースのみに、後者はLinAlgのみに存在し、新しい結合はありません。

4. サイレントvs.ラウド障害：

   提案1は、転置セマンティクスを期待してtransposeを呼び出すと、サイレントに誤った結果になります（ただし、代わりに配列フリップセマンティクスを取得します）。

   提案2のアナログは、配列フリップセマンティクスを期待する非数値配列でtransposeを呼び出しています。 この場合、 transposeはエラーをスローして、ユーザーにflip示すのに役立ちます。

5. .' ： .'非推奨にしないための主な引数は、 transposeの長さです。 提案1は、 .'をtransposeおよびconjadjointという名前に置き換えますが、この状況は改善されません。 対照的に、提案2はflipとtransposeという名前を提供し、その状況を改善します。

1.0へのパスの違い

各提案の下で1.0に到達するには何が必要ですか？ 1.0へのパスは、提案2の方が簡単なので、そこから始めましょう。

提案2の下での1.0への道

1. LinAlgに怠惰な随伴および転置ラッパータイプを導入します。たとえば、 AdjointとTransposeです。 mul[!] / ldiv[!] / rdiv[!]メソッドを導入し、これらのラッパータイプにディスパッチし、対応するA[c|t]_{mul|ldiv|rdiv}_B[c|t][!]メソッドのコードを含めます。 前者のメソッドの短い子として後者のメソッドを再実装します。

   この手順は何も中断せず、 .'の特別な引き下げの削除と非推奨の両方を即座に有効にします。

2. A[c|t]_{mul|ldiv|rdiv}_B[c|t]を生成する特別な下げを削除します。代わりに、単に' / .'をAdjoint / Transpose下げます。 以前は特別に下げられた式でA[c|t]_{mul|ldiv|rdiv}_B[c|t]呼び出しが発生し、代わりに同等のmul / ldiv / rdiv呼び出しになります。 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!]を対応するmul[!] / ldiv[!] / rdiv[!]メソッドに非推奨にします。 .'推奨にします。

   これらの手順は0.7で実行できます。 それらは2つのことだけを壊します：（1）非Base / LinAlgタイプのA[c|t]_{mul|ldiv|rdiv}_B[c|t]メソッドをヒットするために特別な下げに依存するコードは壊れます。 このようなコードは、明示的なMethodErrorを発行し、新しい低下が何をもたらすか/壊れたコードを何に移行する必要があるかを示します。 （2）分離された' s / .'依存するコードは、厳密に熱心に動作すると壊れます。 一般的な障害モードも明示的なMethodError必要があります。 至る所で、破損は制限され、騒々しいです。

   1.0に厳密に必要な変更については以上です。

   この時点で、 Adjoint(A) / Transpose(A)は怠惰な随伴作用素と転置を生成し、 adjoint(A) / transpose(A)は熱心な随伴作用素と転置を生成します。 後者の名前は無期限に残るか、必要に応じて、0.7の他のスペル、たとえばeagereval(Adjoint(A)) / eagereval(Transpose(A))モジュロスペルのeagerevalまたはeageradjoint(A)廃止される可能性があります。 eagertranspose(A) 。 非推奨の場合、 adjoint / transposeは1.0で再利用できます（ただし、 Adjoint(A) / Transpose(A)がありますが、そうなるかどうかはわかりません。必要）。

   最終的に...

3. Base flipおよび/またはFlipを導入します。 機能の追加であるため、この変更は必要に応じて1.xで発生する可能性があります。

提案1の下での1.0への道

提案1はどうですか？ 以下に、2つの可能なパスの概要を示します。 最初のパスは0.7の変更を統合しますが、サイレントブレークを伴います。 2番目のパスは、サイレントブレークを回避しますが、0.7-> 1.0の変更が多く含まれます。 どちらのアウトラインも、コードベースを継続的に進化させています。 継続性の低い同等物は、一部の作業/チャーンを統合/回避する可能性がありますが、より困難でエラーが発生しやすい可能性があります。 進行中の作業は、最初のパスをたどっているようです。

提案1の最初のパス（サイレントブレークあり）

1. transposeのセマンティクスを転置から配列フリップに変更し、必然的にすべてのtranspose関連機能のセマンティクスも変更します。 たとえば、 At_...始まるまたは..._Bt[!]終わるすべてのA[c|t]_{mul|ldiv|rdiv}_B[c|t][!]メソッドは、セマンティックリビジョンが必要になる可能性があります。 また、たとえばSymmetric / issymmetricの定義と動作も変更する必要があります。 transpose自体をBaseます。

   これらの変更は、静かにそして広く壊れるでしょう。

2. LinAlg conjadjointを導入します。 このステップでは、前のステップで触れたすべてのメソッドを復元する必要がありますが、元のセマンティック形式で、 conjadjoint関連付けられた異なる名前（たとえば、 Aca_...と..._Bca[!]名前）を使用します。 。 また、配列フリップ（現在はtranspose ）、転置（現在はconjadjoint ）、およびLinAlg随伴を同時にサポートする追加の型の組み合わせのメソッドを追加する必要があります（たとえば、 ca A[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!]中のcaバリアント）。

3. （と呼ば怠惰な随伴し、転置を紹介conjadjointで） LinAlg言う、 AdjointとConjAdjoint 。 Baseにレイジー配列フリップ（ transposeと呼ばれる）ラッパータイプを導入します（例： Transpose 。 mul[!] / ldiv[!] / rdiv[!]メソッドを導入し、これらのラッパータイプにディスパッチし、対応するA[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!]メソッドのコードを含めます。 前者のメソッドの短い子として後者のメソッドを再実装します。

4. A[c|t]_{mul|ldiv|rdiv}_B[c|t]を生成する特別な下げを削除します。代わりに、単に' / .'をAdjoint / Transpose下げます。 以前は特別に下げられた式でA[c|t]_{mul|ldiv|rdiv}_B[c|t]呼び出しが発生し、代わりに同等のmul / ldiv / rdiv呼び出しになります（ただし、セマンティクスはサイレントに変更されることを思い出してください）。 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!]を対応するmul[!] / ldiv[!] / rdiv[!]メソッドに非推奨にします。 同様に、最近導入されたAca_... / ...Bca[!]メソッドを削除して、 mul[!] / ldiv[!] / rdiv[!]相当するものを優先します。 .'推奨にします。

これらの変更は0.7で行う必要があります。 既存の操作に対するセマンティックの変更は、広範囲にわたるサイレントな破損をもたらします。 特別な下降除去は、上記と同じ閉じ込められた大きな破損をもたらします。

この時点で、 Adjoint(A) / Transpose(A) / ConjAdjoint(A)はそれぞれ、怠惰な随伴、配列反転、転置、およびadjoint(A) / transpose(A) / conjadjoint(A)はそれぞれ、熱心な随伴、配列反転、転置を生成します。 後者の名前は無期限に残るか、必要に応じて、0.7でも他のスペルに廃止される可能性があります（上記を参照）。

このプロセスの早い段階でConjAdjoint導入して、一部の作業/チャーンを統合/回避することができますが、このアプローチはより困難でエラーが発生しやすい可能性があります。

提案1の2番目のパス（サイレントブレークを回避）

1. LinAlg熱心なconjadjointを導入します。 現在transpose関連付けられているすべての機能とメソッド（たとえば、 tを含むA[c|t]_{mul|ldiv|rdiv}_B[c|t][!]メソッドを含む）をconjadjointと派生名に移行します。 すべてのtranspose関連の名前を、新しいconjadjoint相当するものの短い子にします。 すべてのtranspose関連の名前をconjadjoint相当するものに非推奨にします。

2. LinAlgにレイジー随伴および転置（ conjadjointと呼ばれる）ラッパータイプを導入します。たとえば、 AdjointとConjAdjointです。 mul[!] / ldiv[!] / rdiv[!]メソッドを導入し、これらのラッパータイプにディスパッチし、対応するA[c|ca]_{mul|ldiv|rdiv}_B[c|ca][!]メソッドのコードを含めます。 前者のメソッドの短い子として後者のメソッドを再実装します。

3. Transposeと呼ばれる怠惰な配列フリップラッパー型をBaseに導入します（同時にtransposeは転置セマンティクスでconjadjoint非推奨になるため、やや混乱します）。 array-flip（ Transpose ）が機能するために必要なすべての一般的なメソッドをBase追加します。 次に、配列反転（現在はTransposeですが、 transposeはありません）、転置（現在はconjadjoint ）を同時にサポートするすべての追加の型の組み合わせについて、 LinAlgにメソッドを追加します。およびConjAdjoint ）、およびLinAlg随伴には、（たとえば、 A[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!]相当するmul[!] / rdiv[!] / ldiv[!] ）が必要です。現在存在しない）。

4. A[c|t]_{mul|ldiv|rdiv}_B[c|t]を生成する特別な下げを削除します。代わりに、単に' / .'をAdjoint / Transpose下げます。 以前は特別に下げられた式でA[c|t]_{mul|ldiv|rdiv}_B[c|t]呼び出しが発生し、代わりに同等のmul / ldiv / rdiv呼び出しになります。 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!]を対応するmul[!] / ldiv[!] / rdiv[!]メソッドに非推奨にします。 .'廃止します。

上記の変更は0.7で行う必要があります。 サイレント破損はなく、上記の特別な下降除去による大きな破損のみです。

この時点で、 Adjoint(A) / Transpose(A) / ConjAdjoint(A)はそれぞれ、怠惰な随伴、配列反転、転置を生成します。 adjoint(A) / conjadjoint(A)は、それぞれ熱心な随伴作用素と転置行列を生成します。 transpose(A)はconjadjoint非推奨になります; transposeは、必要に応じて1.0で再利用できます。 adjointは無期限に残るか、0.7の別のスペルを優先して非推奨になる可能性があります。 conjadjointを綴る別の方法は、0.7に直接入ることができます。

手順1と2をある程度統合して、一部の作業/チャーンを回避することもできますが、このアプローチはより困難でエラーが発生しやすい可能性があります。

＃

読んでくれてありがとう！

素晴らしい記事をありがとう。 私は一般的に提案2にも同意しますが、随伴作用素はまったく標準的な用語ではなく、個人的には非常に混乱していると思います（随伴作用素は数学の特定の分野で単純な転置の用語として使用されることがあるため、追加の形容詞活用共役が起こることを意味しているようです）。

上記の手の込んだ議論を読んでみましたが、数学的なtransposeが再帰的であることが決定/動機付けられた時点がわかりませんでした。 これは、いくつかの個人的な議論（7月14日から18日のどこか）に続くようで、その後突然、数学的および構造的な転置が導入されました。
@ Sacha0はそれを

それがどのように発生したか：以前は「構造転置」は「数学的随伴」/「数学的転置」と混同されていました

（構造的）転置が「随伴」と混同されたことに同意しますが、ここでは「数学的な転置」がどこからともなく現れますか？ 完全性/自己完結性のために、その概念とそれが再帰的である必要がある理由を簡単に繰り返し/要約することができますか？

これに関連して、行列の転置が作用しないオブジェクトになるという単純な理由から、線形マップの演算として、抽象的な数学的な意味でtransposeを実際に使用している人はいないと思います。ベクトルですが、 RowVectorにあります。つまり、 RowVectorをRowVectorマップします。 再帰的転置についての議論が不足していることを考えると、通常（基本依存）概念として定義される単純な行列転置と、新しく提案されたflip操作との間に違いはありません。

素晴らしい記事を書いてくれてありがとう@ Sacha0 。 私は（コールが随伴案2を好むadjoint転置、 transpose 、および配列フリップflip 。 adjointとtransposeライブでLinAlg 、およびflipはBaseます。） 私には、これが最良の最終結果をもたらすように思われ（これが主な関心事であるはずです）、v1.0のよりクリーンな方法も可能にします。 私は上記のあなたのポイントに同意するので、それらを繰り返すことはしませんが、ここにいくつかの追加のコメントがあります。

非再帰的なtransposeを支持する1つの議論は、 .'構文が非常に便利であり、したがって、たとえばMatrix{String}使用できるということです。 構文は（＃21037）離れて起こっている、もう1つは使用する必要があると仮定するとtranspose(A)の代わりにA.' 、私はと思いますflip （短い-functionは歓迎のほかになりますtranspose(A)よりも明確で、 permutedims(A, (2,1))よりも間違いなく優れています）。

提案2が提供するLinAlgとBase間の分離も非常に優れています。 LinAlgは、 TransposeとAdjoint処理方法だけを気にする必要があるだけでなく、 transposeとadjointを考慮することも明確になります。 LinAlg演算であり、 flipは行列の次元を反転するだけの一般的なAbstractMatrixものです。

最後に、 transpose(::Matrix{String})などが機能しないという苦情はあまり見られません。 それは本当に一般的なユースケースですか？ ほとんどの場合、とにかく最初から反転した行列を作成する方が良いはずです。

この命名スキーム（提案2）は確かに優れているかもしれません。 随伴と転置は線形代数のかなり標準的な用語であり、壊れにくいです...

しかし、数学的な転置が再帰的であるべきであることがどの時点で決定/動機付けられたかを知ることができませんでした

@Jutho随伴作用素（複素数の随伴作用素は共役である（複素数は有効なランク1のベクトル空間と線形演算子であるため、内積と随伴作用素が適用される）、およびブロック行列の随伴作用素と同じ引数です。再帰的です...）。 たとえば、ネストされた実数行列を使用して線形代数を実行したい場合があります。 「実数の行列またはベクトルの随伴作用素」に.'を使用するコードがまだたくさんあり、これも以前は行っていました。 ここで、 'は有効であるだけでなく、より一般的でもあります（複雑な値やネストされた配列で機能します）。 ネストされた複素行列での再帰転置のより本物の使用法は、方程式がconj(adjoint(a))与えるときに発生します。これは比較的まれですが、それでも発生します（それに関連付けられた関数がない場合は、私が満足するほどまれです。上記の議論や他の場所で、さまざまな人々がそれを「数学的な転置」のような異なるものと呼び始めました。私はconjadointを選びましたが、おそらくtranspose自体を除いて、優れた用語IMOはありません。 線形代数では、ブロック行列のブロックを再配置するが、ブロック自体には何もしない非再帰的操作は、通常は表示されません。

最後に、 transpose(::Matrix{String})などが機能しないという苦情はあまり見られません。 それは本当に一般的なユースケースですか？ ほとんどの場合、とにかく最初から反転した行列を作成する方が良いはずです。

ジュリアの放送事業では、こういうことはかなり望ましいと思います。 たとえば、一部のデータの外部（デカルト）積を取得し、それを関数を介してマッピングすることは非常に一般的です。 したがって、 map(f, product(a, b))ようなものの代わりに、 broadcast(f, a, transpose(b))または単にf.(a, b.')を使用できます。 それは少数のキャラクターで大きな力です。

私の考え：このスペースにさらに多くの関数名（つまりflip ）を追加しないようにするために、 permutedims(a) = permutedims(a, (2,1))順列のデフォルト値を使用できるかどうか疑問に思っています。 残念ながら、これはflipほど短くはありませんが、完全なpermutedims(a, (2,1))フォームよりも不快感が大幅に少なくなります（より一般的な機能についてユーザーに教えるという副作用があります）。

（ @ Sacha0ここにごAdjointとTransposeラッパー、またはRowVector + MappedArray +反転したものを選択してください以前に計画されたマトリックス（たぶんPermutedDimsArray ）、私はまだ後者を好む傾向があります...）

ネストされた複素行列での再帰転置のより本物の使用法は、方程式がconj(adjoint(a))与えるときに発生します

方程式でconj(adjoint(a))を取得したら、行列エントリに適用したいのは実際にはconjであり、 adjointではない可能性があることをどのようにして知ることができますか。 adjoint.(adjoint(a)) 。

これはおそらく私を禁止/追放するでしょうが、私は再帰的なアイデア全体の大ファンではありません。 私も必ずしもそれに反対しているわけではありません。ベクトルと演算子/行列は再帰的に定義されていないため、数学的に厳密な理由があるとは思いません。スカラーのフィールド上で（必要に応じて拡張リングによって）定義されます。ベクトル空間の代わりにモジュールも操作します）。 したがって、Base.LinAlgはその場合にのみ機能するはずです。 主な議論

ベクトルの随伴は、それをスカラーにマッピングする線形演算子でなければなりません。 つまり、aがベクトルの場合、a '* aはスカラーでなければなりません。

Julia Baseの動作と互換性がありません： a=[rand(2,2),rand(2,2)] 、 a'*aを観察します。 スカラーではありません。 それで、 aは行列で満たされたベクトルなので、今は行列ですか？ 上記は、モジュールを定義したスカラーとして2x2行列のリングを実際に使用することを意図している場合にのみ、スカラーです。 しかし、それらの文脈では、上記の結果が意図したものであるかどうかは私にはわかりません。 とにかく、ユークリッド内積がモジュールなどのコンテキストで使用されることはめったにないので、Baseがその正しい動作を定義することすら気にする必要はないと思います。

したがって、実際には、上記のステートメントは、行列で満たされた行列をブロック行列として解釈することを超えて動機を拡張する試みである可能性がありますが、最終的には、ブロック行列の解釈がadjointを作成する唯一の真の動機であったと思います。 transpose （数学的な意味では決して使用されませんが、常にフリップ行列インデックスの意味で使用されます）でさえ、そもそも再帰的です。 新しいスカラーフィールドタイプを自分で定義する場合、使用する前に、 conjに加えてadjointとtransposeを定義する必要があるのは奇妙な負担です。マトリックスで。

だから、なぜ、ジュリアのような強力な型システムでは、単にブロック行列専用の型を持っているだけではありません。 したがって、悪魔の代弁者を演じること：

• 実際の仕事で随伴作用素の現在の再帰的振る舞いを実際に使用/依存している人は何人いますか？
• そのような再帰的アプローチを使用している他の言語はありますか？ （Matlabは、行列のセルを使用しますが、使用しません）

すでに述べたように、特にtranspose場合は、（上記の説明をすべて読んだ後でも）有効性を疑問視するだけで、必ずしも反対するわけではありません。

これはおそらく私を禁止/追放するでしょう

これは冗談だと思いますが、不評な意見を持っていても、誰も禁止されることはありません。 長期間続く悪い行動だけが禁止につながる可能性があります。 それでも禁止は恒久的ではあり

ベクトルと演算子/行列は再帰的に定義されていないため、数学的に厳密な理由はないと思います。スカラーのフィールド上で定義されます（ベクトル空間の代わりにモジュールも操作する場合は、拡張リングによって定義されます）。 ）。

この声明は私には意味がありません。 ベクトルのベクトル、関数のベクトル、または行列のベクトルは、 +と* scalar再帰的に定義されたベクトル空間（基礎となるスカラー場上）を形成し、同様に形成されます。内積が再帰的に定義された内積空間。 ベクトルは「スカラーの列」にしかなり得ないという考えは、数学、物理学、工学における定義と一般的な使用法の両方に反します。

a=[rand(2,2),rand(2,2)] 、 a'*aを観察します。 スカラーではありません。

この場合、 aの「スカラーリング」は2x2行列のリングです。 したがって、これは言語の問題であり、随伴作用素の動作の問題ではありません。

ジュリアで現在どのように機能するか（または機能しないか）からa'*aがどのように機能するかについて

新しいスカラーフィールドタイプを自分で定義する場合、使用する前に、 conjに加えてadjointとtransposeを定義する必要があるのは奇妙な負担です。マトリックス内

この負担は実際的というよりも美的だと思います。 Numberサブタイプにすることに問題がない場合は、何も定義する必要はありません。 Numberが適切ではないと思われる場合でも、定義は非常に簡単です。それらを追加することはほとんど負担ではありません。

だから、なぜ、ジュリアのような強力な型システムでは、単にブロック行列専用の型を持っているだけではありません。

https://github.com/KristofferC/BlockArrays.jl/寄稿者を歓迎します:)

「禁止」ジョークについてお詫びします。 これ以上この議論を狂わせないために、これが私の最後の反応になります。 再帰的随伴作用素（転置ではないかもしれません）が解決されることは明らかであり、私はその決定を元に戻そうとはしていません。 私はいくつかの矛盾を指摘しようとしています。

@StefanKarpinski ：スカラーリングの例は再帰とNumberタイプがスカラーですか？

前者の場合、実際にはベクトル空間の代わりにモジュールがあり、それらの「スカラー」にconjまたはadjointどちらが必要かは、ユースケースによって異なります。内積と随伴を使用します。

私は後者の定義を受け入れても大丈夫です。 私は仕事で超ベクトル空間の段階的テンソル積のグループ不変部分空間で任意の要素を使用しているので、ベクトルの定義で数値の列に実際に限定されていません。 しかし、行列のベクトルは、純粋なベクトルなのか、それとも何らかの行列の動作を継承する必要があるのか​​。 前者の場合、 dot(v,w)は、おそらくその要素でvecdotを再帰的に呼び出すことにより、スカラーを生成する必要があります。 後者の場合、少なくともvecdot(v,w)は、再帰的に動作することによってスカラーを生成する必要があります。 したがって、これは再帰的随伴と一致するための最小限の修正になります。

しかし、再帰的なtransposeを持たず、数学以外のアプリケーションにも使用できるようにする方が簡単なようです。通常の行列方程式でも、実際の数学的な転置とはほとんど関係がないと思うからです。線形マップの。

dotはvecdotではなくdot再帰的に呼び出す必要があると思います。したがって、行列の正規内積を定義しないため、行列のベクトルに対してエラーが発生します。

転置が再帰的であることにいつも驚いています..そして誰もがそうではないとは想像できません。 （この議論のおかげで、「線形マップの転置」ウィキペディアの記事に対する見解は少なくとも3倍になったと思います。）

私も再帰的定義が不安定であることに気づき、 ました（しかし、再び非常によく似たトレーニングを受けました）。

ここで私を悩ませている矛盾を理解したと思います-ここでは例として複素数の2x2行列埋め込みなどのリングとフィールドを使用し続けていますが、実際には機能せず、再帰転置（および随伴）を動機付けません）。

説明させてください。 私が広く同意すること

1. スカラーは有効なランク1の線形演算子です。 ジュリアの強力な型システムが与えられない理由はありませんLinAlgのような概念adjoint 、我々が定義する必要があり、たとえば、適用されないadjoint(z::Complex) = conj(z) 。 （スカラーのベクトルと行列を超えて、 LinAlg概念を（ユーザーによって）他のオブジェクトに拡張することもできます- @ stevengjは、たとえば無限サイズのベクトル空間（ヒルベルト空間）について言及しました）。
2. さまざまな表現のスカラーをなんとかして処理できるはずです。 ここでの典型的な例は、複素数z = x + y*imをZ = x*[1 0; 0 1] + y*[0 1; -1 0]としてモデル化でき、演算+ 、 - 、 * 、 /と\は、この同型で保持されます。 （ただし、 conj(z)はadjoint(Z) / transpose(Z) / flip(Z)ます。これについては後で詳しく説明します）。
3. ブロック行列はどういうわけか可能であるはずです（現在のアプローチはデフォルトで再帰的なadjointなどに依存しています）。

Base.LinAlgが1および2と互換性があることは合理的と思われますが、IMO 3は、自然に収まる場合にのみBase必要があります（そうでない場合は、https：/などの外部パッケージに従う傾向があります/github.com/KristofferC/BlockArrays.jl）。

私は今、私たちが2と3を混同していることに気づき、これはいくつかの矛盾につながります（ adjointやその他の操作をブロック行列に従って使用しても、2。最も簡単な方法は例によるものではm = [z1 z2; z3 z4] 、同型表現M = [Z1 Z2; Z3 Z4] 、および標準の2x2ブロック行列b = [m1 m2; m3 m4]として定義しましょう。ここで、 m1などは同じサイズの正方形です。 Number行列。 一般的な操作の意味的に正しい答えを以下に示します。

| 操作| z | Z | m | M | b |
| -| -| -| -| -| -|
| + 、 - 、 * | 再帰的| 再帰的| 再帰的| 再帰的| 再帰的|
| conj | conj(z) | Z'またはZ.'またはflip(Z) | conj.(m) | adjoint.(M) （またはtranspose.(M) ）| conj.(b) |
| adjoint | conj(z) | Z'またはZ.'またはflip(Z) | flip(conj.(m))または再帰的| flip(transpose.(m))または再帰的| 再帰的|
| trace | z | Z | z1 + z4 | Z1 + Z4 | trace(m1) + trace(m4) |
| det | z | Z | z1*z4 - z2*z3 | Z1*Z3 - Z2*Z3 | det(m1) * det(m4 - m2*inv(m1)*m3) （ m1可逆の場合、たとえばWikipediaを参照）|

スカラーを返すtraceやdetような演算を考えると、 LinAlg Julia型システムがComplex 2x2行列埋め込みを処理できないことは明らかだと思います。 trace(Z)で、 Z = [1 0; 0 1]は2 、これは1表現です。 同様にrank(Z) 。

一貫性を回復する1つの方法は、2x2表現をスカラーとして明示的に定義することです。たとえば、次のようにNumberサブタイプ化します。

struct CNumber{T <: Real} <: Number
    m::Matrix{T}
end
CNumber(x::Real, y::Real) = CNumber([x y; -y x])

+(c1::CNumber, c2::CNumber) = CNumber(c1.m + c2.m)
-(c1::CNumber, c2::CNumber) = CNumber(c1.m - c2.m)
*(c1::CNumber, c2::CNumber) = CNumber(c1.m * c2.m)
/(c1::CNumber, c2::CNumber) = CNumber(c1.m / c2.m)
\(c1::CNumber, c2::CNumber) = CNumber(c1.m \ c2.m)
conj(c::CNumber) = CNumber(transpose(c.m))
zero(c::CNumber{T}) where {T} = CNumber(zero(T), zero(T))
one(c::CNumber{T}) where {T} = CNumber(one(T), one(T))

これらの定義により、一般的なLinAlgメソッドはおそらく正常に機能します。

私がこれから導き出した結論：再帰的なadjointは、ブロック行列とベクトルのベクトルにとって便利です。 上記のZとラベル付けした「スカラー」2x2行列のタイプの数学的正確さによって動機付けられるべきではありません。 次の長所と短所を使用して、デフォルトでブロック行列をサポートするかどうかを選択します。

長所

• ブロックアレイユーザーの利便性
• ベクトルのベクトルは有効なベクトル空間であり、ブロック行列は+ 、 * 、 conjなどの下で有効な線形演算子です。これを自然な同形にすることが可能であれば（ CNumberを必要とする上記のZ例とは異なり）、なぜですか？

短所

• LinAlg実装に大幅な追加の複雑さ（別のパッケージに存在する可能性があります）。
• eig(block_matrix)ようなものをサポートするのは少し難しいです（しかし不可能ではありません）。 LinAlgがeigをサポートし、 LinAlgがブロック行列をサポートすると言う場合、修正されるまでこれはバグと見なします。 LinAlgによって提供される大量の機能を考えると、私たちが「完成」することはほとんどありません。
• transposeような操作を非再帰的に使用したいデータユーザーの不便、

私にとっての質問は-デフォルトでLinAlgはAbstractArrayの要素が「スカラー」（ Numberサブタイプまたはダックタイピング）であることを期待していると言うことを選択しますか？ブロック配列の複雑さを外部パッケージに反映させますか？ それとも、 BaseとLinAlgの複雑さを受け入れますか？

前日までの計画は後者でした。

@ Sacha0ここでの変更をサポートするために必要なRowVector作業を完了しようとしています（以前の変更：非再帰的なtranspose 、 RowVectorサポート文字列およびその他のデータ）そして今、私はあなたがデザインに関して何を考えていたのか疑問に思います。

最近の議論から、私はこれらのケースを何が望まれるかを推測して見ています

| | ベクトル| マトリックス|
|-|-|-|
| adjoint | RowVectorと再帰adjoint | AdjointMatrixまたはTransposedMatrixと再帰的なadjoint |
| transpose | RowVectorと再帰transpose | TransposeMatrixと再帰transpose |
| flip | コピーまたはPermutedDimsArray ？ | コピーまたはPermutedDimsArray ？ |
| conjのAbstractArray | 怠惰または熱心？ | 怠惰または熱心？ |
| conj RowVectorまたはTransposedMatrix | 怠惰| 怠惰|

（上記は、線形代数の懸念をデータの配列の次元の並べ替えから分離しようとしています。）

だから私を解き放つためのいくつかの基本的な質問：

• 再帰的なtransposeいますか？ adjointどうですか？
• もしそうなら、私たちはconj(transpose(array)) == adjoint(array)を仮定し続けますか？
• たとえば、余分なコピーなしで現在のすべてのBLAS操作をサポートするために、少なくともいくつかの複雑な活用は怠惰になるようです。 すべてのアレイでconj遅延させますか？
• flipを紹介する場合、それは怠惰ですか、それとも熱心ですか？

参考までに、 permutedims短い形式を使用して、＃24839で行列の次元を「反転」する低摩擦アプローチを試しました。

私は@ Sacha0の提案2に強く賛成です。再帰的随伴作用素と非再帰的随伴作用素の理論的基盤を完全に整理していませんが、それとは独立して、少なくとも私にとっては、現在どのように役立つことがわかっています。 、そしてそれからの土壇場での変更はおそらくお勧めできません。 転置は、必要な場合は、この点で随伴（= conj∘adjoint ）に従う必要があります。

FWIW、Mathematicaは再帰的なTransposeもConjugateTransposeもしません：

上記の手の込んだ議論を読んでみましたが、数学的な転置が再帰的であることが決定/動機付けられた時点がわかりませんでした。 [...]完全性/自己完結性のために、その概念とそれが再帰的である必要がある理由を簡単に繰り返し/要約できますか？

私はこの感情を理解し、感謝しており、時間の許す限りそれに対処したいと思います。 随伴と転置が定義上再帰的である必要がある理由をアクセス可能かつ明快に説明することは、残念ながらせいぜい挑戦的であり、簡単には不可能である可能性があります。 上記のような首尾一貫した包括的な記事は、作成に膨大な時間を要します。 短い時間ですが、その代わりに、前のいくつかの投稿の混乱のいくつかに、その中の特定のポイント/質問に答えることによって対処しようとします。 私が少しずつそうしている間、私に耐えてください:)。 ベスト！

随伴作用素が定義上再帰的である理由を説明する…

この議論に貢献した私はかなり誰もがadjoint(A)が再帰的であるべきだということに同意しています。 唯一の論点は、 transpose(A)も再帰的である必要があるかどうか（および非再帰的転置のために新しい関数flip(A)を導入する必要があるかどうか）です。

この議論に貢献した私は、adjoint（A）が再帰的であるべきであることに同意するかなりの人です。

たとえば、https：//github.com/JuliaLang/julia/issues/20978#issuecomment-347777577および以前のコメントを参照してください:)。 ベスト！

再帰的随伴の議論は、定義のかなり基本的なものです。 dot(x,y)は内積、つまりスカラーを生成する必要があり、随伴の定義はdot(A'*x, y) == dot(x, A*y)です。 再帰（ dotとadjoint両方）は、これら2つのプロパティから得られます。

（ドット積との関係が、随伴と転置が線形代数の重要な演算である理由です。そのため、行列を90度回転するような他の演算ではなく、それらの名前が付けられています（Matlabではrot90 ）。 ）。）

非再帰的転置にflipを使用する場合の問題の1つは、MatlabとNumpyの両方がflipdimと呼ばれるものにflipを使用することです。

行列の転置がベクトルではなくRowVectorに作用するオブジェクトになる、つまりRowVectorをマップするという単純な理由から、線形マップの操作として、抽象的な数学的な意味で転置を実際に使用している人はいないと思います。 RowVectorに。

しかし、再帰的な転置がなく、数学以外のアプリケーションにも使用できるようにする方が簡単なようです。通常の行列方程式でも、線形マップの実際の数学的な転置とはほとんど関係がないと思います。

転置（数学的な意味では使用されませんが、常にフリップ行列のインデックスの意味で使用されます）

これは少し回り道のように見えるので、我慢してください:)。

ジュリアのadjointは、特にエルミート随伴を指します。 一般に、UとVの場合、それぞれの双対空間U *とVを持つ完全なノルムベクトル空間（バナッハ空間） 、および線形写像A：U-> Vの場合、通常Aで 。 つまり、一般に、転置A ^ tが上記のように双対空間間の線形写像であるのと同様に、随伴は双対空間間の線形写像です。 では、これらの定義をエルミート随伴のよく知られた概念とどのように調和させるのでしょうか？ :)

答えは、通常作業するスペース、つまり完全な内積空間（ヒルベルト空間）が持つ追加の構造にあります。 内積はノルムを誘導するので、完全な内積空間（Hilbert）は完全なノルム空間（Banach）であり、それによって（エルミティアン）随伴の概念をサポートします。 重要な点は次のとおりです。単なるノルムではなく内積を持つことで、線形代数で最も美しい定理の1つ、つまりリースの表現定理が適用されます。 一言で言えば、リースの表現定理は、ヒルベルト空間はその双対空間と自然に同型であると述べています。 したがって、ヒルベルト空間を扱う場合、通常、空間とその双対を識別し、区別を削除します。 その識別を行うことは、A *：V *-> U *ではなくA *：V-> Uとしてのエルミート随伴のよく知られた概念に到達する方法です。

また、ヒルベルト空間を考慮する場合、転置についても同じ識別が一般的に行われ、A ^ t：V-> Uとなり、おなじみの転置の概念が得られます。 したがって、明確にするために、はい、転置の一般的な概念は、最もよく知られている（ヒルベルト）設定に適用される転置の一般的な概念です。ちょうどエルミート随伴の一般的な概念がその設定に適用される随伴の一般的な概念であるのと同じです。 ベスト！

死んだ馬を殴ったことをお詫びしますが、数学的な混乱の問題を別の方法で簡単に要約したいと思いました。 不一致の重要な点は、 Tが配列のような下部構造を持たないNumber単なるサブタイプではない場合に、オブジェクトVector{T}を数学的に解釈する方法です。

ある学派は@stevengjの主張を受け入れます

環R上のベクトルのベクトルは、R上のベクトル空間でもある直和空間として最もよく理解されます。

無限次元のベクトル空間などに関する特定の微妙なモジュロ。これは基本的に、ベクトルのベクトルをブロックベクトルと見なす必要があることを意味します。 したがって、 Vector{Vector{T<:Number}}は、精神的に単純なVector{T} 「フラット化」する必要があります。 このパラダイム内では、行列の行列として表される線形演算子は、ブロック行列と同様に考える必要があり、 adjointは、 transpose単語を使用している場合と同様に、確実に再帰的である必要があります。数学的意味。 私が間違っている場合は訂正してください。しかし、この観点をとる人々は、 Vector{Matrix{T}}ようなものには、私たちが設計すべき自然な解釈がないと考えていると思います。 （特に、 @ stevengjが言ったように、内側のMatrixが複素数の行列表現であると単純に仮定するべきではありません。

複素数を2x2行列で表す場合、異なる複素数ベクトル空間があります。

）

もう1つの考え方は、 Vector{T}は常に、タイプTスカラー（線形代数の意味で）上の抽象的なベクトル空間でのベクトルの表現と考えるべきであるというものです。タイプに関係なくT 。 このパラダイムでは、 Vector{Vector{T'}}は直和空間の要素としてではなく、スカラーVector{T'}上のベクトルとして考えられるべきです。 この場合、 transpose(Matrix{T})は再帰的であってはならず、単に外側の行列を反転させる必要があります。 この解釈の1つの問題は、型Tの要素が有効なスカラーのリングを形成するために、（可換）加算と乗算の明確に定義された概念がなければならないということです。 Vector{Vector{T'}}ようなベクトルの場合、2つの「スカラー」 Vector{T'}を別のVector{T'}に乗算するためのルールが必要になります。 確かにそのようなルールを思い付くことができますが（たとえば、問題をT'乗算方法にまでパントする要素ごとの乗算）、そうするための普遍的な自然な方法はありません。 もう1つの問題は、この解釈の下でadjointがどのように機能するかということです。 エルミート随伴作用素は、ヒルベルト空間上の線形演算子でのみ定義されます。ヒルベルト空間のスカラー場は、定義上、実数または複素数のいずれかでなければなりません。 したがって、 adjointを行列Matrix{T}に適用する場合は、 Tが複素数（または実数）の表現であると想定する必要がありますが、ここで説明します。その場合はより微妙なので複雑です）。 この解釈では、 adjointは再帰的であってはなりませんが、外側の行列を反転してからconjugate適用する必要があります。 ただし、 conjugate(T)の正しいアクションは表現の性質に依存するため、ここにはさらに問題があります。 ウィキペディアで説明されている2x2表現の場合、 conjugateはマトリックスを反転させる必要があります。 ただし、上記の理由により、 conjugateは常に行列を反転する必要はありません。 したがって、このアプローチを実装するのは少し面倒です。

これが私自身の考えです。要素がさらに複雑な下部構造を持つ配列に適​​用されたときにtransposeが再帰的であるかどうかについて、「客観的に正しい」答えはありません。 これは、ユーザーがJuliaで抽象的な代数的構造を表現するためにどの程度正確に選択しているかによって異なります。 それでも、スカラーの完全に任意のリングをサポートすることは非常に難しいように思われるので、実用性のために、それほど野心的なことを試みるべきではなく、非標準のリング上のモジュールの難解な数学を忘れるべきだと思います。 Base （ permutedims(A, (2,1))よりも単純な構文）には、線形代数の転置の概念とは関係がなく、行列を反転するだけで、再帰的であるかどうかに関係なく、関数が必要です。 transposeまたはflipなどと呼ばれます。 adjointとLinAlg内の個別の転置関数（おそらく別の名前）が再帰的であると、ブロックベクトル/行列と直接和の単純な実装を処理できるので便利です。ベクトルのベクトルとしてですが、これは「客観的な数学的正しさ」では必要ありません。純粋に実装の容易さを理由にその決定を下すのは問題ありません。

もうコメントしないという私の以前の約束にもかかわらず、残念ながら私はこれに応答しなければなりません。

ジュリアの随伴作用素は、特にエルミート随伴作用素を指します。 一般に、UとVの場合、それぞれの双対空間U *とVを持つ完全なノルムベクトル空間（バナッハ空間） 、および線形写像A：U-> Vの場合、Aのエルミート随伴（通常はAで

本当にそれは真実ではありません。 ここで説明しているのは実際には転置ですが、（すでに述べたように）一部のフィールドでは、これは随伴（エルミートなし）と呼ばれ、A ^ tまたはA ^ *（A ^ daggerではありません）として示されます。 実際、それはベクトル空間をはるかに超えて拡張され、圏論では、そのような概念は任意のモノイド圏（たとえば、線形写像としてコボルディズムを持つn次元配向多様体の圏論）に存在し、そこでは隣接メイトと呼ばれます（実際、左右の双対空間は必ずしも同じではないため、2つの異なるAとAが存在する可能性があります。 ただし、これには複素共役が含まれないことに注意してください。 V *の要素は確かに線形写像f：V->スカラーであり、線形写像A：U-> VとUからのベクトルvの場合、f（Av）=（A ^ tf）（v）となります。 。 fの作用は複素共役を伴わないので、A ^ tの定義も含まれません。

答えは、通常作業するスペースが持つ追加の構造、つまり完全な内積空間（ヒルベルト空間）にあります。 内積はノルムを誘導するので、完全な内積空間（Hilbert）は完全なノルム空間（Banach）であり、それによってエルミート随伴の概念をサポートします。 重要な点は次のとおりです。単なるノルムではなく内積を持つことで、線形代数で最も美しい定理の1つ、つまりリースの表現定理が適用されます。 一言で言えば、リースの表現定理は、ヒルベルト空間はその双対空間と自然に同型であると述べています。 したがって、ヒルベルト空間を扱う場合、通常、空間とその双対を識別し、区別を削除します。 その識別を行うことは、A *：V *-> U *ではなくA *：V-> Uとしてのエルミート随伴のよく知られた概念に到達する方法です。

繰り返しますが、私はそれが完全に正しいとは思いません。 内積空間では、内積はconj（V）x V-> Scalar（conj（V）を使用した複素ベクトル空間）からの半双線型形式dotです。 これにより、実際にVからV *（または技術的にはconj（V）からV *）へのマップを確立できます。これは実際にリースの表現定理です。 ただし、エルミート随伴作用素を導入するためにそれは必要ありません。 実際、内積dot自体で十分であり、線形写像Aのエルミート随伴は次のようになります。
dot(w, Av) = dot(A' w, v) 。 これには複素共役が含まれます。

本当にそれは真実ではありません。 ここで説明しているのは実際には転置ですが、（すでに述べたように）一部のフィールドでは、これは随伴（エルミートなし）と呼ばれ、A ^ tまたはA ^ *（A ^ daggerではありません）として示されます。 [...]

@Jutho 、例えば、エルミート随伴のウィキペディアのページをご覧ください。

たぶん、数学の異なる分野の間で矛盾がありますが、：
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map
特に
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map#Relation_to_the_Hermitian_adjoint
圏論における数え切れないほど多くの参考文献、例えば
https://arxiv.org/pdf/0908.3347v1.pdf

https://en.wikipedia.org/wiki/Transpose_of_a_linear_map
特に
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map#Relation_to_the_Hermitian_adjoint

@Jutho 、そのページセクションと上記のリンク先のページに記載されている定義との間に矛盾は見られません。また、上記に投稿した内容との矛盾も見られません。 ベスト！

@ Sacha0の提案2にもサインオンします。今のところ、1つの引数permutedimsでも問題ありません。 flipよりはましだと思います。

@ Sacha0の場合、それを解釈する別の方法があります。 私はこれを次のように読みました
与えられたA：U-> Vに対して、
transpose（A）= dual（A）=（時々）adjoint（A）：V *-> U *
エルミート随伴作用素（A）=短剣（A）=（通常はちょうど）随伴作用素（A）：V-> U
そして、両者の関係は、空間から双対空間（すなわち、Riesz ...）へのマップを使用することによって正確に取得されます。これには、複素共役が含まれます。 したがって、エルミート随伴は活用を含みますが、転置は含みません。

最初の1つをエルミート随伴と呼びたい場合、転置とは何と呼びますか？ あなたはそれがあなたの説明に何であったかを実際に定義していませんでした、あなたはちょうど言及しました

Aのエルミート随伴は、通常Aで表され、線形写像A ：V *-> U *です。 つまり、一般に転置A ^ tが双対空間間の線形写像であるのと同様に、一般にエルミート随伴は双対空間間の線形写像です。

では、転置とエルミート随伴は、A：U-> VをV- > Uからマップに変換する2つの異なる方法ですか？ これについてさらに話し合うことができれば幸いですが、他の場所でこれを行う方がよいと思います。 しかし、実際には、これについてもっと知りたいと思っているので、私に連絡してください。

また、 http： //staff.um.edu.mt/jmus1/banach.pdfを参照して、バナッハ空間のコンテキストで使用される随伴作用素が実際には転置であり、エルミート随伴作用素ではないことを参照して

Julia Baseの場合：私は再帰的なエルミート共役に反対していません。 私はそれがしばしば正しいことになることに同意します。 要素タイプがNumberない場合、Baseが賢いことをしようとするべきかどうかはわかりません。 Tが数値であっても、Baseでは、非ユークリッド内積（および関連する随伴の修正定義）のはるかに一般的な使用法はサポートされていません。また、サポートされるべきではないと思います。 したがって、主な動機はブロック行列だったと思いますが、特別な目的のタイプ（Baseまたはパッケージ内）ははるかにジュリアンであり、 @ andyferrisも述べたように、他のすべてのLinAlgとは異なります。 LinAlgは、 invような単純なもの（行列の因数分解などは言うまでもなく）でさえ、ブロック行列の概念をサポートします。

しかし、再帰的なエルミート共役がここにとどまる場合（私は問題ありません）、一貫性を保つために、 dotとvecdotは要素に対して再帰的に動作する必要があると思います。 現在、これは当てはまりません。 dotは要素に対してx'yを呼び出し（要素が行列の場合は同じではありません）、 vecdotはdot呼び出します。要素に。 したがって、行列のベクトルの場合、実際にはスカラー結果を取得する方法はありません。 現在の実装が再帰的なadjointと実際に矛盾していないことに人々が同意する場合は、PRを準備できれば幸いです。

transpose 、非再帰的にし、数値データを処理しない人にも使用させる方が簡単なようです。 行列を扱うほとんどの人はtransposeという用語を知っていて、それを探すと思います。 再帰的なtransposeが必要な場合は、まだconj(adjoint())があります。

トリアージは、 @ Sacha0が提案2を進めて、試してみる必要があると考えています。

私は@ttparkerに強く同意します。再帰的随伴は選択であり、数学的に一貫した唯一のオプションではありません。 たとえば、次のように簡単に述べることができます。

1 -〜 LinAlg 、 AbstractVector vは、（スカラー）基底重みv[1] 、 v[2] length(v)次元ベクトルです。 v[2] 、...、 v[length(v)] 。

（同様にAbstractMatrix ）。

これはおそらく、多くの人が他のライブラリから来るという仮定であり、基底ベクトル、ランクなどのこのような単純な定義を持つことは、実装を単純に保つのに役立ちます。 （多くの人は、数値線形代数は、うまく機能するように設定された優れた基底関数を持っているという理由だけで、コンピューターに実装することが可能であると言うでしょう。）

現在のアプローチは次のようなものです。

2-からLinAlgまで、 AbstractVector vは、 length(v)抽象ベクトルの直和です。 また、 Numberようなスカラー型に十分な定義を含めて、 LinAlgそれらが有効な1次元線形演算子/ベクトルになるようにします。

（ブロック）行列についても同様です。 これは、MATLAB、numpy、eigenなどの線形代数の実装よりもはるかに一般化されており、これが実現可能であるというJuliaの強力なタイプ/ディスパッチシステムを反映しています。

オプション2が望ましいと私が考える包括的な理由は、ジュリアのタイプ/ディスパッチシステムにより、漠然と次のような、はるかに広い目標を設定できることです。

3 - LinAlg 、 + 、 * 、 conj下で線形性（など）を満たすオブジェクトに対して機能する汎用線形代数インターフェースを作成しようとしています。

これは本当にクールな目標であり（私が知っている他のプログラミング言語/ライブラリをはるかに超えています）、再帰的なadjointと2を完全に動機付けます（ + 、 *そしてconj自体が再帰的である）とSacha0の提案2とトリアージの決定は良い選択である理由

これについてさらに話し合うことができれば幸いですが、他の場所でこれを行う方がよいと思います。 しかし、実際には、これについてもっと知りたいと思っているので、私に連絡してください。

乾杯、やろう！ さらにオフラインでチャットするのを楽しみにしています:)。 ベスト！

素敵なまとめアンディ！ :)

少なくともadjoint （これはあなたのコメントのトピック

しかし、私が永遠に平和を保つ前に、非再帰的なtransposeに対する最後の嘆願が1つあります（願わくば）。
次の利点がある非再帰的転置があります。

• 数値以外のデータが含まれている場合でも、行列を使用するすべての人が使用できます。 それはまた、他の言語から、そして非数値的なユースケースに外挿された基本的な数学から、彼らがこの操作を知ってそれを探す方法でもあります

• 怠惰なflipタイプまたはPermutedDimsArrayをLinAlgと相互作用させるために、追加のコードを記述する必要はありません。 転置する代わりに反転した数値行列がある場合はどうなりますか。 それでも他の行列（できればBLASを使用）で乗算することはできますか？

• 非再帰的なtransposeと再帰的なadjointを使用すると、 conj(transpose(a))と再帰的な転置conj(adjoint(a))ような非再帰的な随伴作用素を簡単に作成できます。 それでも、すべてがLinAlgとうまく相互作用します。

では、欠点は何ですか。 何も見えません。 私はまだ、数学的な意味でtransposeを使用している人は誰もいないという私の主張を支持しています。 しかし、これ以上議論しようとする代わりに、再帰転置が必要または有用であり、実際には数学的な転置である具体的な例を誰かに教えてもらえますか？ これは、実際にadjointを使用するつもりであったが、実数を持っているだけの例を除外します。 したがって、それ自体が複素数値であるより多くの行列で満たされたベクトルまたは行列を転置する数学的な理由があるアプリケーション。

少なくともMathematica（これにかなりの考えを注いだと予想される）は再帰的な転置を行わないと言うことができます：

A = Array[1 &, {2, 3, 4, 5}];
Dimensions[A]  # returns {2, 3, 4, 5}
Dimensions[Transpose[A]] # returns {3, 2, 4, 5}

編集：おっと、これも上にコメントされました、ごめんなさい

だから私は混乱しています。 transposeを非再帰的にする必要があるというかなり堅実なコンセンサスがあったようです-例： https ： https：//github.com/ JuliaLang / julia / issues / 20978＃issuecomment -285942526、 https： //github.com/JuliaLang/julia/issues/20978#issuecomment -285993057、 https ： //github.com/JuliaLang/julia/issues/20978#issuecomment- 348464449、およびhttps://github.com/JuliaLang/julia/pull/23424。 次に、 @ Sacha0は2つの提案を行い、そのうちの1つは再帰的な転置を残しますが、非再帰的なflip関数を導入します。これは、（私が知る限り）以前は可能性として実際に提起されていなかったにもかかわらず、強力なサポートを得ました。 。 次に、 @ JeffBezansonは、 permutedimsにデフォルトの2番目の引数を指定すれば、結局flipは必要ないと提案しました。これも、強力なサポートを得ています。

したがって、今では、 transposeに対する唯一の実際の変更は、「舞台裏」である必要があるというコンセンサスのようです。通常のエンドユーザーがおそらく知らない、または気にしない、特別な下げと怠惰な評価と熱心な評価に関してです。 。 実際に目に見える変更は、基本的にスペルの変更だけです（ .'を減価償却し、 permutedimsにデフォルトの2番目の引数を指定します）。

したがって、コミュニティのコンセンサスは非常に短い時間でほぼ180度変化したようです（ @ Sacha0の投稿https://github.com/JuliaLang/julia/issues/20978#issuecomment-347360279の頃）。 Sachaの投稿はとても雄弁だったので、みんなの心を変えただけでしたか？ （もしそうならそれでいいのですが、ほんの数日前に私たち全員が間違っていたと思われていた道を進んでいるように見える理由を理解したいだけです。）

誰かがこれを提案したかどうかは忘れますが、 transpose(::AbstractMatrix{AbstractMatrix}) （そしておそらくtranspose(::AbstractMatrix{AbstractVector})も）を再帰的にし、そうでなければtranspose非再帰的にすることができますか？ それはすべてのベースをカバーするようであり、 tranposeを再帰的にしたい他のユースケースは考えられません。

したがって、コミュニティのコンセンサスは非常に短い時間でほぼ180度変化したようです（ @ Sacha0の投稿＃20978（コメント）の頃）。 Sachaの投稿はとても雄弁だったので、みんなの心を変えただけでしたか？ （もしそうならそれでいいのですが、ほんの数日前に私たち全員が間違っていたと思われていた道を進んでいるように見える理由を理解したいだけです。）

私がとても雄弁だったら😄。 あなたが見ているのは、コンセンサスが実際には形成されていなかったということです。 むしろ、（1）現状を支持するが、消耗のために議論から撤退した参加者は、意見を表明するために戻った。 （2）現状からの脱却が実際に何を伴うか（そしてそれがリリースの考慮事項とどのように関係するか）を考慮しなかった他の当事者は、現状を支持するより強い意見を形成し、その意見を表明した。

この議論は継続中でされていることを考慮してください一つの形態または別の2014年以来、githubの上の、そしておそらくそれ以前のオフライン。 長期的な参加者にとって、そのような議論は疲れ果てて周期的になります。 この議論に参加する以外に意味のある仕事があります---コードを書くことのように、より楽しいです---その結果、それらの長期参加者の間で減少が生じます。 その結果、会話はある期間または別の期間に偏ったように見えます。 個人的には、私はその減少のしきい値に近づいているので、この議論に従事し続けるのではなく、今はコードを書くことに集中するつもりです。 どうもありがとうございました！ :)

AbstractArrayの非再帰的転置とctransposeに賛成票を投じます。どちらも、T <：AbstractArrayであるAbstractArray {T}で再帰的です。

再帰的な動作が「正しい」場合があることに同意します。この質問は、パッケージを使用および開発している人にとって、最小限の驚きで正しい動作を実現する方法であると考えています。
この提案では、カスタム型の再帰的転置動作はオプトインです。型をAbstractArrayにするか、適切なメソッドを定義することでオプトインします。
Base.transpose(AbstractArray{MyType})またはBase.transpose(AbstractArray{T}) where T<: MyAbstractType 。
再帰的転置（質問せずに再帰するだけ）のダックタイピング戦略は、上記のようにいくつかの驚きを生み出すと思います。 別個のctransposeとadjoint、またはconjadjointとflipのようなより複雑な提案を導入すると、ユーザーはこれらに遭遇してそれらを使用しようとし、パッケージメンテナーはそれらすべてをサポートしようとします。

新しい提案ではサポートが難しいものの例として、normal、transpose、ctranspose、およびconj配列はすべて、ReshapeArrayおよびSubArrayビューと相互運用するビュー（または遅延評価）を持つことができる必要があります。 （これらがデフォルトでビューを生成するのか、 @viewを使用する場合にのみ生成されるのかはわかりません。）これは、フラグ「N」を使用したA*_mul_B*下げと低レベルのBLAS呼び出しの作業に接続します。他の場所で説明されているように、高密度アレイの場合は「T」および「C」。 これらは、 normal 、 transpose 、 ctranspose 、およびconjを処理した場合に推論しやすくなります
対等の立場で。 BLAS自体は、通常の場合は「N」、転置の場合は「T」、ctransposeの場合は「C」のみをサポートし、接続詞のフラグがないことに注意してください。これは間違いだと思います。

最後に、高次元の配列と形状変更との一貫性を保つために、転置とctransposeの適切な一般化は、すべての次元を逆にすることだと思います。
transpose（A :: Array {T、3}）= permutedims（A、（3、2、1））。

乾杯！

実際に仕事をしてくださっている方々に心から感謝しています。 @andyferrisがステップアップしてこれを実装するまで、あまりにも長い間議論されてきたのは、ベクトル随伴/転置です（ただし、再帰的な側面はありません）。これは非常にうまく機能します。 同様に、配列コンストラクターの継続的な再設計にも大いに感謝します。 そのすべてに親指を立てます。

そうは言っても、行列の転置と随伴/ ctransposeは、特に再帰的な側面についてはあまり議論されませんでした。これは、 https：//github.com/JuliaLang/julia/pull/7244で単一の動機付けブロック行列としてほとんど静かに紹介されました

これらの議論ではいくつかの別々のことが起こっていますが、今、迅速に実行できる計画が必要になっています。

• LinAlg 、ブロック行列（およびよりエキゾチックな構造）をサポートする価値があるかどうかについて説明しました。 実装の選択肢は次のとおりです。再帰的なものはまったくありません（ + 、 * 、 conjは、Juliaのジェネリック関数の性質であるため）、すべてを再帰的に（現状）、または、要素が再帰線形代数を実行するか、スカラーとして扱われるかについて、ある種のタイプチェックまたは特性を試行します。
• ユーザーがデータの2D配列の次元を並べ替えるための優れた方法が必要です。 非再帰的なtranspose 、 flip 、短縮されたpermutedims構文があります（PRは、実装する文字が最も少ないという理由だけで最初に送信されたものであり、おそらく意味があります。他のことも行う場合）、要素が再帰的転置を行う必要があるかどうかのある種の型チェックまたは特性（おそらくtranspose(x::Any) = x ...を再導入することさえあります）。
• Juliaパーサーは、 x' * y -> Ac_mul_B(x, y)ような奇妙な動作をしますが、これは少し疣贅ですが、v1.0には理想的には存在しません。 これは、高速BLAS（余分なコピーなし）をサポートできるようになるまで実現可能とは見なされていません。したがって、レイジーマトリックスの転置と随伴です。
• LinAlgのコードは非常に大きく、何年にもわたって構築されています。 行列の乗算のような多くのものは、おそらく新しいbroadcastようなディスパッチシステムを使用して、より特性に適したものにリファクタリングすることができます。 これは、適切な配列（ストライド行列の共役再形成されたajdointedビューのPermuteDimsArrayを考えています）をBLASに簡単に送信できる場所だと思います。 ただし、これによってv1.0が作成されることはなく、コードを大幅に悪化させることなくパフォーマンスの低下を回避しようとしています。 Sachaが指摘したように（そして私が発見しているように）、要素に対してさまざまな動作（再帰的随伴、再帰的転置、活用、何もない）を持つ転置ビューがあると、複雑さが増し、物事を機能させ続けるための新しい方法がたくさんあります。です。

v1.0を言語をある程度安定させるものと考えると、ある意味で、動作を変更するための最優先事項は3番目のものです。 言語（パーサーを含む）が最も安定している必要があり、次にBase 、次にstdlib（ LinAlgが含まれる場合と含まれない場合がありますが、ほぼ確実に含まれると思います） BLAS 、 Sparseなど）。 これはユーザー（主にライブラリ開発者）に実際には影響を与えない変更なので、ここで人々の意見が異なっていても驚かないでしょう。

アンディにスポット！ :)

ここでやらなければならないことは、デフォルトでadjointとtranspose怠惰にすることだけだと思いますか？

これは今すぐ閉じることができますか？

次は：「スカラー転置を真剣に受け止める」

しかし、真剣に、PDEソルバーで使用されるさまざまな3D転置とテンソル乗算を指定するための優れたインターフェイスを使用できますか？ ちょっと深刻ですが、この狂気の次の反復へのOPになることができるかどうかはわかりません。

番号

:)

PDEソルバーで使用されるさまざまな3D転置およびテンソル乗算を指定するための優れたインターフェイスを使用できますか？

間違いなくパッケージの良い主題のようです。

さまざまな3D転置およびテンソル乗算を指定するための優れたインターフェイス

TensorOperations.jlは、ここで必要なことを実行しませんか？ （このレベルでは、「優れたインターフェイス」とは、 TensorOperationsの構文よりも簡潔にコードを記述するのが少し難しい、テンソルネットワーク図のようなものを意味することに注意してください）。

ええ、TensorOperations.jlはよさそうです。 少し冗談でしたが、必要なものを手に入れました👍。