たとえば、ベクトル 'ベクトル'はベクトル（＃2472、＃2936）を生成し、ベクトル 'は行列を生成し、ベクトル' 'は行列（＃2686）を生成します。これらはすべて悪い数学です。

有限次元のベクトル空間の双対は、それと同型であり、同一ではありません。 ですから、これがどのように悪い数学なのかはっきりしていません。 人間の脳はそのような滑りやすい曖昧さを処理し、正しいことをするのが得意なので、数学で同型であるものの違いを理解する傾向があります。 とはいえ、これを改善する必要があることに同意しますが、数学的に正しくないためではなく、煩わしいためです。

v' == v 、しかしv'*v != v*vどうすればよいですか？ x' * yが独自の演算子であると私たちが思っていたよりも理にかなっていますか？

有限次元のベクトル空間の双対は、それと同型であり、同一ではありません。

（今私自身と言えば）それは単なる同型ではなく、自然に同型です。つまり、同型は基底の選択とは無関係です。 この種の同型とアイデンティティを区別する価値のある実用的なアプリケーションは考えられません。 IMOの煩わしさの要因は、この種の区別をすることから来ています。

x' * yが独自の演算子であると思っていたよりも理にかなっていますか？

それが、今日の午後の@alanedelmanとの話し合いから得た印象でした。

ジェフが求めているのはお金の問題だと思います...それはx'_yのように見え始めており、x_y 'はより多くを稼いでいます
これまで以上にセンス。

私は@stefanと暴力的に合意しています。 悪い数学は、間違った数学を意味するものではありませんでした。
迷惑な数学を意味することを意味しました。 技術的には正しいものがたくさんありますが、あまり良くありません...。

このロジックを使用する場合、ここに2つの選択肢があります

x_xはエラーのままです.....おそらく「ドットを使用したい」という提案があります
またはx_xは内積です（私はその選択が好きではありません）

xとx'が同じものである場合、 (x')*yがdot(x,y)を意味するようにしたい場合は、 x*yもdot(x,y)あることを意味します。 x'yとx'*yを別の操作にすることもできますが、それが素晴らしいアイデアかどうかはわかりません。 人々はこれを明白な方法で括弧でくくり、それでも機能させたいと思っています。

x*xが内積を意味することを許可した場合、基本的に戻ることはできないことを指摘しておきます。 それは至る所で人々のコードに入れられ、それを根絶することは悪夢になるでしょう。 したがって、自然同型であろうとなかろうと、これは純粋数学ではなく、コンピューター内のさまざまなものが異なるという事実に対処する必要があります。

これが、私が好きな「アップタプル」と「ダウンタプル」を区別するための実践的な議論です。

http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book-ZH-79.html#％_idx_3310

「vector」や「dual」などの単語は慎重に避け、迷惑な人を避けるためです。 しかし、偏導関数への適用は説得力があると思います。

http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book-ZH-79.html#％_sec_Temp_453

M[1,:]とM[:,1]を区別するもう1つの理由は、現在、ブロードキャスト動作によってこの非常に便利な動作が許可されていることです。 M./sum(M,1)は列確率的であり、 M./sum(M,2)は行確率的です。 。 norm関数を「修正」して、行と列に簡単に適用できるようにすると、正規化についても同じことができます。 もちろん、上下のベクトルの代わりにsum(M,1)とsum(M,2)戻り行列を使用することもできますが、それは少しずれているようです。

私は上下のベクトルのアイデアが好きです。 問題は、完全に狂気ではない方法でそれをより高い次元に一般化することです。 または、ベクトルを特別な場合にすることもできます。 しかし、それも間違っていると感じます。

アップ/ダウンは別の理論かもしれないのは事実です。 それらを一般化するアプローチはネストされた構造のようであり、それは物事を異なる方向に導きます。 彼らがそれらをベクトルと呼ばない理由がある可能性が非常に高いです。

また、 x*y = dot(x,y)は、 x*(y*z)と(x*y)*zように、 *非連想にします。 それを避けられることを心から願っています。

はい。 私にとって、それは完全に受け入れられません。 つまり、技術的には、浮動小数点*は非連想的ですが、ほぼ連想的ですが、これは明らかに非連想的です。

x*xは内積であってはならないことに私たちは皆同意します。

v'wとv'*wを内積と考えることができるかどうかという疑問が残ります-
私はこれがそのように機能するのが本当に好きです。

@JeffBezansonと私はチャットしていました

提案は次のとおりです。

v'はベクトルのエラーです（これは数学が行うことです）
v'wおよびv'*wは内積です（結果=スカラー）
v*wは外積行列です（結果=行列）

行と列のベクトルの区別はありません。 とにかくこれが好きだった
数学の前例を見てうれしかった
mathematicaから： http ：
Mathematicaがベクトルと行列を表すためにリストを使用する方法のため、「行」ベクトルと「列」ベクトルを区別する必要はありません。

ユーザーは、行ベクトル....期間がないことに注意する必要があります。

したがって、 Mが行列の場合

M[1,:]*vはエラーです.....（ M[1,:]を使用すると仮定すると、スカラーです
警告は、 dotまたは'*またはM[i:i,:]試すことを示唆している可能性があります

M[[1],:]*vまたはM[1:1,:]*vは長さ1のベクトルです（これはとにかくジュリアの現在の動作です）

https://groups.google.com/forum/#!topic/julia -users / L3vPeZ7kewsの密接に関連する問題について

Mathematicaはスカラーのような配列セクションを圧縮します：

m = Array[a, {2, 2, 2}] 


Out[49]= {{{a[1, 1, 1], a[1, 1, 2]}, {a[1, 2, 1], 
   a[1, 2, 2]}}, {{a[2, 1, 1], a[2, 1, 2]}, {a[2, 2, 1], a[2, 2, 2]}}}

In[123]:= Dimensions[m]
Dimensions[m[[All, 1, All]]]
Dimensions[m[[2, 1, All]]]
Dimensions[m[[2, 1 ;; 1, All]]]

Out[123]= {2, 2, 2}

Out[124]= {2, 2}

Out[125]= {2}

Out[126]= {1, 2}

[編集：コードフォーマット– @StefanKarpinski]

@alanedelman

M [1 、：]はスカラーであると仮定します

M [1 、：]は単なるベクトルという意味ですか？

うん、ごめん。 私の考えは、M [1 、:]がスカラー1を処理していたことを意味しました:-)

Mathematicaはアスタリスク*ではなくピリオド.使用します
次に、9ヤード全体を移動し、（vector .vector）をスカラーにします。これはまさに私たちが避けていることです。
アスタリスク付き。

期間には間違いなく多くの問題がありますが、その1つはそうではないということです
ドット積の「ドット」のように見えますが、もう1つは、それが衝突することです。
ドットの「ポイントワイズ操作」の読み、

Unicodeは、「ドット演算子」という名前の文字を非常にうまく提供します
⋅ (char(8901))これは私たちが提供することを想像できます

したがって、 (v ⋅ w)を(v'*w)同義語にすることができます。

要約すると、議論の対象となる現在の提案は次のとおりです。

1. スカラーインデックスはディメンションを強制終了するため、
   A[i,:]は、 A[:,i,j]同様にベクトルです。
2. ベクトルインデックスは厚い
   A[ i:i , : ]またはA[ [i], : ]は、1行の行列を返します
3. v'wまたはv'*wは、ベクトルの内積です（同様に、外積の場合はv*w' ）。
4. v'はベクトルに対して未定義です（ユーザーをpermutedims(v,1)ポイントしますか????）
5. Aが行列の場合、 v*Aはベクトルを返します
6. v⋅wも内積を返します（ただし、行列を操作することにより、数学の.までは行きません
7. v*wはベクターに対して未定義ですが、警告がユーザーに次のような適切な提案を提供する可能性があります
   ⋅

結果はそれです

a。 列ベクトルであるすべてのベクトルに固執すると、すべてが機能します
b。 すべてをマトリックスにすると、すべてが確実に機能し、すべてをマトリックスにするのは簡単です。
c。 行ベクトルと1行の行列を区別できない場合は、教育を受ける可能性があります。
丁寧かつ優雅に
d。 このドット表記⋅は、見た目には心地よいものです。

提案5）私には非常に奇妙に見えます。 双対ベクトルを使用していることが明示されるように、 v'*Aを使用します。 これは、デュアルが単なる「形状」変換ではない複雑なベクトル空間で特に重要です。

@StefanKarpinskiに、このすべてで簡潔なブロードキャスト動作を失うのはかなり残念だと反響したいと思います。 この変更後、ベクトルvを取得し、それらの値によって行列Aの列を正規化するための簡潔な構文は何ですか？ 現在、 A ./ v'使用できます。 これは、データ操作に非常に適しています。

良い質問

私のスキームは、 v'*Aがvの複素共役を取り、Aで乗算することを排除していません。
そして、私がまだ明示的に言及しなかったが、すぐにできる他のさまざまなケースすべて

5を排除することができます
おそらくそれが望ましい
列ベクトルのルールに準拠していません

放送へのこのアプローチはかわいくて不器用です
現在の解決策の1つはA ./ v[:,[1]]

どのディメンションがブロードキャストされているかを文書化するという利点があります
より高次元の配列に一般化します

ああ、 v[:,[1]]ソリューションには、複素共役をとらないという利点があります
これはおそらくユーザーが意図していることです.....

最初の例は線形代数の例であるため、これら2つの例が好きです
複素共役が非常に頻繁に必要とされる場合、2番目の例は
物事をすべての次元で機能させたい多次元データの例
行列だけでなく、複雑な共役は必要ない可能性が非常に高いです

⋅は＃552が必要です。 過去2週間で3回目です。

M [1 、：]とM [：、1]を区別するもう1つの理由は、現在、ブロードキャスト動作によってこの非常に便利な動作が可能になることです。M。/ sum（M、1）は列確率的であり、M。/ sum（M、 2）行確率的です。 ノルム関数を「修正」して行と列に簡単に適用できるようにすれば、正規化についても同じことができます。 もちろん、上下のベクトルの代わりにsum（M、1）とsum（M、2）の戻り行列を使用することもできますが、それは少しずれているようです。

放送の振る舞いが良い場合もあるように思えますが、それらの余分なユニットを絞らなければならないこともあります。 したがって、システムの残りの部分が優れている場合は、逆のことを行う必要がある場合は問題ありません（スカラー次元を削除すると、システムが優れたものになると思います）。 したがって、次のような関数が必要になります

julia> widen(A::AbstractArray,dim::Int) = reshape(A,insert!([size(A)...],dim,1)...)
# methods for generic function widen
widen(A::AbstractArray{T,N},dim::Int64) at none:1

これにより、 M ./ widen(sum(M,2),2)やA ./ widen(v,1)ようなコードが許可されます（上記の@blakejohnsonの例を参照）

M [：、0 、：]およびv [：、0] ?????

削減の問題については、 @ blakejohnsonの方が好きです。 個人的には、 widenよりもsqueezeの方が明確だと思います。 widenが指定されたインデックスの前後にディメンションを挿入するかどうかを判断するためにドキュメントを絶えず調べていると思います。一度に複数のディメンションに拡大する場合は、番号付けが少し複雑になります。 （何widen(v, (1, 2))ベクトルに対してvこれらのいずれのですか？）のための問題であるsqueeze 。

デフォルトで拡大するか縮小するかに関係なく、拡大に関してはJuliaがnumpyの先導に従い、 v[:, newaxis]ようなものを許可する必要があると思います。 しかし、私は寸法を破棄するのではなく保持することを好むと信じています。間違った方向に絞ったときよりも、誤って間違った方向に広げたバグを見つけるのは難しいです（通常はエラーが発生します）。

@alanedelmanのリスト
私はそのように感じる

Aが行列の場合、v * Aはベクトルを返します

良くない。

Aが1x1（インデックスの範囲の不一致）でない場合、v_Aはエラーになります。
v'_Aはそれを行うための適切な方法である必要があります。

この問題を処理する1つの方法は、ベクトルvをnx1行列に自動的に変換することです（必要な場合）。
常にv 'を1xn行列として扱います（ベクトルまたはnx1行列に変換しないでください）
また、1x1行列をスケーラー番号に自動的に変換することもできます（必要な場合）。

これは、線形代数についての一貫した均一な考え方を表していると思います。 （良い数学）

これらすべての問題を処理するための統一された方法は、自動（型？）変換を許可することです（必要な場合）
サイズ（n）、（n、1）、（n、1,1）、（n、1,1,1）などの配列間（ただし、サイズ（n、1）と（1、n）の配列間ではありません） ）
（必要に応じて実数を複素数に自動的に変換するのと同じように）

この場合、サイズ（1,1）の配列を（必要に応じて）数値に変換できます（＃4797を参照）。

Xiao-Gang（物理学者）

これはv'_Aを残しますしかし....私は本当にv'_A * wを機能させたいです

ジュリアでの線形代数の私の印象は、スカラーと真のベクトルが存在するにもかかわらず、それが行列代数のように非常に組織化されているということです（これは良いと思います！）

x*y*z*wような積を処理する方法を考えてみましょう。ここで、各因子はスカラー、ベクトル、または行列であり、おそらく転置されています。 行列代数は、行列の積を定義します。ここで、行列のサイズはn x mです。 1つのアプローチは、この定義を拡張して、 nまたはmをabsentに置き換えることです。これは、製品の計算に関する限り、1の値のように機能します。 、ただし、スカラーとベクトルを行列から区別するために使用されます。

• スカラーはabsent x absent
• （列）ベクトルはn x absent
• 行ベクトルはabsent x n

理想的には、行ベクトルを表す必要がないように配置したいのですが、 x'*yやx*y'ような操作を実装するだけで十分です。 これが私たちの多くが探しているスキームの味だと感じます。

しかし、この種のスキームで行ベクトルを禁止すると、コストが高くなるのではないかと私は考え始めています。 例：中間ステップで行ベクトルが形成されないように、製品を括弧で囲む必要がある方法を検討してください（ aはスカラー、 uおよびvはベクトルです）

a*u'*v = a*(u'*v) // a*u' is forbidden
v*u'*a = (v*u')*a // u'*a is forbidden

行ベクトルの生成を避けながら積x*y'*zを評価するには、乗算の順序を選択する前に、因子のタイプを知る必要があります。 ユーザーが自分でそれを行う必要がある場合、それはジェネリックプログラミングの障害のように思われます。 そして、ジュリアがどうやってそれを正しい方法で自動的に行うことができるのかわかりません。

乗算の順序を事前に固定しないもう1つの理由：動的計画法を使用して、必要な操作の数を最小限に抑えるために*(x,y,z,w)の最適な評価順序を選択するというアイデアがあったことを覚えているようです。 行ベクトルの形成を回避するために行うことは、これを妨げる可能性があります。

したがって、現時点では、転置ベクトル型を導入することは、私にとって最も正気な代替手段のように思えます。 それ、または今のようにすべてを実行しますが、それらを保持するときに末尾のシングルトンディメンションを削除すると、エラーが発生します。

転置は、モードを並べ替える特定の方法です。 v.'を許可する場合（ vはベクトル）、 permutedims(v,[2 1])はまったく同じものを返すはずです。 どちらも特別な行ベクトルタイプを返すか、新しいディメンションを導入します。

行ベクトルに特別なタイプを使用することは、私には良い解決策のようには見えません。他のタイプのモードnベクトル、たとえばpermutedims([1:4],[3 2 1])どうするのでしょうか。 決定を下す前に、多重線形代数も考慮に入れることをお勧めします。

@toivohはそれを述べました

「1つのアプローチは、この定義を拡張して、nまたはmを不在に置き換えることです。これは、積の計算に関しては1の値のように機能しますが、スカラーとベクトルを行列から区別するために使用されます。

1. スカラーは存在しないx存在しない
2. （列）ベクトルはnx不在になります
3. 行ベクトルは存在しませんxn "

多重線形代数（または高ランドテンソルの場合）では、上記の提案は、不在を表すために使用しないことに対応します。
範囲1の多くのインデックス、つまりサイズ（m、n、absent）は、（m、n）、（m、n、1）、（m、n、1,1）などに対応する場合があります。

この不在の解釈を使用する場合、1。と2.は問題なく、ありがたいですが、3。は問題ない可能性があります。
サイズ（1、n）と（1,1、n）の配列を混在させたくありません。

私はテンソル理論の専門家ではありませんが、線形代数を含む実質的なプロジェクトには、上記のすべてのシステム（アドオンパッケージなし）を使用しました。

[TL; DR：概要にスキップ]

これは、一般的な行列-ベクトル演算よりも配列処理の一般性を高める必要があると私が感じた最も一般的なシナリオです。

（1）関数解析：たとえば、ベクトル値関数のヘッセ行列を使用するとすぐに、高階テンソルが機能する必要があります。 あなたがたくさんの数学を書いているなら、これらの場合のために特別な構文を使わなければならないことは大きな苦痛でしょう。

（2）評価管理：たとえば、計算可能な製品があれば、その製品のサブエンティティを個別に計算できる必要があります。これは、複数の異なるサブエンティティと組み合わせて異なる製品を形成したい場合があるためです。 したがって、たとえばa*u'が禁止されているというToivoの懸念は、コンパイルの懸念だけでなく、プログラミングの懸念でもあります。 さらに一般的なバリアントは、 x'Qを事前に計算して、2次形式x'Q*y1 、 x'Q*y2 、...を計算することです（これらは順番に実行する必要があります）。

（3）コードの簡略化：多次元データセットにマッピングされた算術演算を処理するときに、システムで6〜7行の不可解なループまたは関数マッピングコードを1つまたは2つの簡単な配列演算に置き換えることができることを何度か発見しました。適切な一般性を提供します。 はるかに読みやすく、はるかに高速です。

上記のシステムでの私の一般的な経験は次のとおりです。

MATLAB：コア言語は、ありふれた行列-ベクトル演算を超えて制限されているため、通常、インデックスを使用してループを作成することになります。

NumPy：MATLABよりも一般的な機能ですが、面倒で複雑です。 ほとんどすべての重要な問題のインスタンスについて、ドキュメントを参照する必要がありましたが、それでも、直感的に定義する必要があると感じた配列操作を自分で実装する必要があることに気付くことがありました。 システムには非常に多くの個別のアイデアがあるため、特定のユーザーと開発者は、相手が何かについてどう考えるかを自動的に推測するのに苦労するようです。 通常、それを行うための短くて効率的な方法を見つけることは可能ですが、その方法は、ライターまたはリーダーにとって常に明白であるとは限りません。 特に、ワ​​イド化とシングルトンディメンションの必要性は、演算子を適用するための実装の一般性の欠如を反映していると感じています（ただし、より直感的に感じる人もいます）。

Mathematica：クリーンで非常に一般的---特に、関連するすべての演算子は高階テンソルの振る舞いを念頭に置いて設計されています。 ドットの他に、たとえば、トランスポーズ、フラット化/パーティション、および内部/外部に関するドキュメントを参照してください。 これらの操作だけを組み合わせることで、ほとんどの配列ジャグリングのユースケースをすでにカバーできます。バージョン9では、コア言語に追加のテンソル代数操作も追加されています。 欠点は、Mathematicaで何かを行う方法がクリーンで理にかなっているとしても（言語を知っている場合）、それを行うための通常の数学表記に明らかに対応していない可能性があることです。 そしてもちろん、一般性のために、コードがどのように実行されるかを知ることは困難です。

scmutils：機能分析の場合、これはクリーンで一般的であり、上記のいずれかで最も数学的に直感的な操作（書き込みと読み取りの両方）を提供します。 アップ/ダウンタプルのアイデアは、実際には、転置記号、微分規則、およびその他の半標準化された概念を使用して、書かれた数学で人々がよく行うことの、より一貫性のある、より一般的な拡張です。 しかし、すべてがうまくいきます。 （博士論文を書くために、私は従来の数学表記に似ているが、Sussman＆WisdomのSICM構文と同型である一貫性のある明確な表記を開発することになりました。）彼らはまた、差分ジオメトリの実装[1]にも使用しました。 SymPyへの移植に影響を与えました[2]。 私はこれをデータ分析に使用していませんが、1種類のタプル（Mathematicaのリストなど）だけが必要な一般的な配列コンテキストでは、慣例により1つ（「上」）を選択できると思います。 繰り返しになりますが、一般性はプログラマーのパフォーマンスに関する考慮事項をあいまいにしますが、これがJuliaが優れている領域であることを願っています。

概要

提案された転置ベクトルタイプは、scmutilsのより一般的な「ダウン」タプルとして特徴付けられるべきだと思いますが、通常のベクトルは「アップ」タプルになります。 それらを「ベクトル」や「転置ベクトル」のようなものと呼ぶことは、それらを「上」や「下」と呼ぶよりもおそらく人々にとって意味があります（簡潔さを犠牲にして）。 これは、次の3つの使用カテゴリをサポートします。

（1）データ分析の場合、ネストされた配列だけが必要な場合は、「ベクトル」のみが必要です。
（2）基本的な行列-ベクトル線形代数の場合、人々は数学的な慣習に直接対応して「ベクトル」と「転置ベクトル」を使用できます（「行列」は「ベクトル」の「転置ベクトル」と同等です）。
（3）高次のテンソル演算（標準化が少なく、とにかく人々が通常考える必要がある場合）の場合、実装は2種類のタプル算術システムの完全な一般性をサポートする必要があります。

このアプローチは、以前の投稿でエラーと見なされたケース（ v'およびv*A ）が実際に意味のある（そして多くの場合有用である）ことを除いて、さまざまな操作の結果に関する上記の新たなコンセンサスを反映していると思います） 結果。

[1] http://dspace.mit.edu/handle/1721.1/30520
[2] http://krastanov.wordpress.com/diff-geometry-in-python/

@thomasmcoffeeは、共変ベクトルと反変ベクトルを明確に区別することを提唱しているように聞こえます。

私はそれを一般的なアプリケーションと考えますが、私が提唱していることに過度に固有です。私にとって、それは（座標表現のための）長方形の数のテンソルへの制限を意味する幾何学的な意味を持っています。 （この分野の専門知識がなくても）標準配列を使用したテンソル代数関数の適切なライブラリが通常この目的には十分であると想像するので、これだけでは2種類のシステムを導入するのに十分な説得力がないというAlanの指摘に共感します。コア言語。

私は主に、より一般的なネストされた構造に依存する他のアプリケーションを考えています。たとえば、混合次元の複数の引数の関数の計算は、コア言語がサポートされていない場合、後で「アドオン」として開発するのがより困難になります。この区別。 たぶん私たちは同じことを意味します。

アップベクトルとダウンベクトルの問題は、アイデアを一般的な配列に拡張する必要があることです。 そうしないと、ベクトルは、配列の1次元の場合ではなく、特別なものになり、配列とは別のものになり、ひどい問題の混乱につながります。 私はそれを行う方法について多くのことを考えましたが、受け入れられるものを思いつきませんでした。 上下のベクトルを配列に正しく一般化する方法について良いアイデアがあれば、ぜひ聞いてみてください。

この考えを推定しようとしているだけです。 私が理解しているように、配列を使用して上下のベクトルで計算するには、次元ごとにそれが上か下かを示す必要があります。 一般に、これは配列を次のようなものでラップすることで実現できます。

immutable UpDownTensor{T, N, UPMASK} <: AbstractArray{T, N}
    A::AbstractArray{T, N}
end

ここで、 UPMASKは、どの次元が上にあるかを示すビットマスクになります。 次に、ラップされていない配列に対する操作は、デフォルトのUPMASKをN関数として提供することで実装できます。ベクトルはデフォルトでシングルアップ、行列は最初のアップと2番目のダウンになります。 それなら、それがどのように合理的に継続されるのかわかりません。

いくつかのランダムな考え：

• 二次/双線形形式は、2つの下の次元でより適切に表現されますか？
• 転置が各次元の上下を反転することに対応する場合、最初の次元が下に、2番目の次元が上にある転置行列タイプも取得されると思います。
• デフォルトに対応するアップパターンは、基になる配列をラップするのではなく、直接表現することができます。

まあ、これは確かにTransposedタイプの1つの一般化であり、確かにいくつかのメリットがあります。 それが実行可能かどうかわからない。

Toivoの提案は、私が上で提唱していたことの合理的な実現だと思います。 私にとって、最も賢明なデフォルトは、高次で方向を交互に繰り返すことです。たとえば、誰かがべき級数のコンポーネントをラップされていない配列として提供した場合、これは正しいことを行います。

しかし、さらに考えてみると、（1）上下のベクトルの違いと（2）配列とベクトルの違いの両方のアイデアを組み合わせることが非常に強力であると思います。 次に、いくつかの次元が上、いくつかが下、いくつかが「中立」であるオブジェクトを持つことができます。 配列とベクトルを区別する理由は、意味的には、配列は編成（同じ種類の複数のものを収集する）用であるのに対し、ベクトルは調整（多次元空間を表す）用であるためです。 1つのオブジェクトで両方の区別を組み合わせることができるのは、これらの両方の目的を同時に果たすことができるということです。 ニュートラルディメンションはブロードキャストルールに従って処理され、アップ/ダウンディメンションはテンソル算術ルールに従って処理されます。

私の以前の例に戻って、さまざまなベクトルy1, y2, ...に対していくつかの2次形式x'Q*y1, x'Q*y2, ...を計算していると仮定します。 SICMに続いて、上タプル（列ベクトル）を(...) 、下タプル（行ベクトル）を[...]ます。 これを一度に実行したいが、アップ/ダウンのみで立ち往生している場合、従来の方法は、ダウンタプルを使用してyiをマトリックスY = [y1, y2, ...]に結合することです。アップタプル）、 r = x'Q*Yを計算します。これにより、ダウンタプルrの結果が得られます。 しかし、これらの各結果に（列）ベクトルvを掛けたい場合はどうでしょうか？ 縮約（内積）が発生するため、 r*vだけを実行することはできません。 rをアップタプルに変換してから乗算すると、（アップタプルの）アップタプルで結果が得られます。 しかし、次のステップでダウンタプルが必要だとしましょう。 意味的には、計算を通過する次元があり、それは常にブロードキャストしたいもののコレクションを表すだけです。 しかし、厳密にアップ/ダウンの世界でこれを達成するには、適切な動作を引き出すために、任意のコンテキスト依存の変換を実行し続ける必要があります。

対照的に、 {...}で示されるニュートラルタプル（配列）もあるとします。 次に、 ys = {y1, y2, ...}を（アップタプルの）配列として自然に記述します。したがって、 r = x'Q*ysは配列であり、 r*vも（アップタプルの）配列です。 すべてが理にかなっており、任意の変換は必要ありません。

Stefanは、1次元配列を上下のベクトルから区別することは悲惨であると示唆していますが、この問題は、ほとんどの関数が配列のベクトルまたはどちらでも動作しないという事実によって解決されると思います。 （または、行列の場合_または_ベクトルの配列の場合_または_配列のベクトルの場合_または_配列の配列の場合_または_ではありませんが、_どちらか_ではありません。自動的に正しいこと。 多分誰かができますか？

深く調べてみると[1]、scmutilsが実際に「ベクトル」と呼ばれるものを内部の上下のタプルと区別していることがわかりました。 ただし、現在、変換ルールは、これらの「ベクトル」がアップ/ダウンの世界に入るたびに（以前に提案したように）アップタプルにマップされるように設定されています。ただし、「この実装を変更して区別する権利を留保します。アップタプルからのスキームベクトル。」 （おそらく、キャンパスの誰かがGJSに特定のアイデアを考えているかどうか尋ねることができます。）Sageシステム[2]は、配列の処理をベクトルと行列から大きく分離し（現在、テンソルのコアサポートはありません）、私が経験した唯一の問題です。これは、明らかに理にかなっている場合に、それらの間に組み込みの変換がないことと関係があります。

[1] http://groups.csail.mit.edu/mac/users/gjs/6946/refman.txt--- 「構造化オブジェクト」から開始
[2] http://www.sagemath.org/

私は昼食の席でましたが、彼はJuliaチームが線形代数演算をより高次元の配列に一般化する方法を

とりあえず、2つのアレイ間の積だけを考えてみましょう。 他の操作にも同様の一般化があります。 配列を扱うときに最も一般的な3つのタイプの積は、外積、内積、および要素ごとの積です。 私たちは通常、 inner(A,B)やA*Bなどの2つのオブジェクト間でこのような操作を行うことを考えています。 ただし、これらの操作を高次元の配列で実行する場合、配列全体ではなく、配列の特定の次元間で実行されます。 複数の外部/内部/要素ごとのサブ操作が2つの配列間の単一の操作で発生し、各配列の各次元を正確に1つのサブ操作に割り当てる必要があります（明示的またはデフォルトのいずれか）。 内側の製品と要素ごとの製品の場合、左側の1つのディメンションを、右側の同じサイズのディメンションとペアにする必要があります。 製品の外側の寸法をペアにする必要はありません。 ほとんどの場合、ユーザーは、次元のペアと他のすべての外積の間で内積または要素ごとの積を実行しています。 外積は最も一般的であり、ペアにする必要がないため、適切なデフォルトになります。

私は通常、プロットのx、y、z軸のように、次元を順序付けではなく名前付きと考えています。 あなたは、ユーザーが実際に注文したインデックス（等によって配列にアクセスできるようにしたい場合でも、 A[1,2,5]ではなくA[a1=1, a3=5, a2=2] ）あなたは、操作の結果を注文する一貫性のある手続きを持っている必要があります。 最初の配列のすべての次元をリストし、次に2番目の配列のすべての次元をリストすることによって結果を順序付けることを提案します。 内積に参加した次元はすべて絞り出され、要素ごとの積に参加した次元の場合、2番目の配列の次元のみが絞り出されます。

これについていくつかの表記法を作成します。 お気軽にジュリアフィしてください。 A a1 x a2 x a3の配列とし、 B b1配列とします。 b2 。 array_product(A, B, inner=[2, 1], elementwise=[3, 2])が次元a2とb1間の内積、 a3とb2間の要素ごとの積、およびa1外積。 結果は、 a1 x a3配列になります。

高次元の配列のコンテキストでは、2項演算子または単項演算子があまり意味を持たないことは明らかです。 各ディメンションをどう処理するかを指定するには、3つ以上の引数が必要です。 ただし、Matlab演算子を最初の2次元のみの配列演算の省略形にすることで、線形代数の容易さを取り戻すことができます。

MatlabのA*Bはarray_product(A, B, inner=[2,1])です。

MatlabのA.'はpermute(A, B, [2,1])であり、permuteは3番目の引数の数よりも高いすべての次元を変更せずに保持します。

Mathematicaがベクトル転置で行うように、配列の次元が2より大きい場合、または2に等しくない場合でも、エラーをスローするかどうかを選択できます。 一般的な配列計算のみを使用している場合は、 @ wenxgwenの提案@ wenxgwenの提案が好きです。

配列計算の連鎖律と積の法則に加えて、加算、べき乗、微分を含む、システムのより

視点をありがとう！ これは、一般的な配列*配列製品が実際にどのような獣であるかを理解するのに非常に啓発的であることがわかりました。

多次元配列乗算の提案を、 PEP0465の行列乗算演算子に対して提案されたセマンティクスと相互参照することは興味深いかもしれません。 特に：

1dベクトル入力は、形状に「1」を追加または追加することによって2dにプロモートされ、操作が実行されてから、追加された次元が出力から削除されます。 1は、常に形状の「外側」に追加されます。左の引数の前に追加され、右の引数の場合に追加されます。 その結果、matrix @vectorとvector @ matrixはどちらも正当であり（互換性のある形状を想定）、どちらも1dベクトルを返します。 vector @ vectorはスカラーを返します... 1dベクトルのこの定義の欠点は、@が非結合になる場合があることです（（Mat1 @ vec）@ Mat2！= Mat1 @（vec @ Mat2））。 しかし、これは実用性が純粋さを打ち負かす場合のようです

Pythonでのダッキング入力は、特別な問題を引き起こします。 当然、配列と行列は交換可能である必要があります（同じ基になるデータ）。 ただし、Pythonは型のチェックを推奨しないため、配列を期待する関数の先頭で行列が正しいインターフェイスにキャストされません。その逆も同様です。 これが、異なる演算子文字が必要な理由です。 ランタイム型チェックとconvertメソッドを使用するJuliaは、このあいまいさの影響を受けません。

PEP 0465から：

1Dベクトルに対するこの定義の欠点は、@が非結合になる場合があることです（（Mat1 @ vec）@ Mat2！= Mat1 @（vec @ Mat2））

特に、この種の定義はMathematicaで誤った結果を生成する可能性があります。これは、 Dot （ . ）がシンボリックに評価されたときに結合法則（ Flat ）であると見なされるためです（ fと同様）。以下のgはありません）：

In[1]:= f=X.(y.Z);
g:=X.(y.Z)

In[3]:= Block[{
X=Array[a,{2,2}],
y=Array[b,2],
Z=Array[c,{2,2}]
},{f,g}]

Out[3]= {{(a[1,1] b[1]+a[1,2] b[2]) c[1,1]+(a[2,1] b[1]+a[2,2] b[2]) c[2,1],(a[1,1] b[1]+a[1,2] b[2]) c[1,2]+(a[2,1] b[1]+a[2,2] b[2]) c[2,2]},{a[1,1] (b[1] c[1,1]+b[2] c[2,1])+a[1,2] (b[1] c[1,2]+b[2] c[2,2]),a[2,1] (b[1] c[1,1]+b[2] c[2,1])+a[2,2] (b[1] c[1,2]+b[2] c[2,2])}}

In[4]:= SameQ@@Expand[%]
Out[4]= False

@drhagenから：

ランタイム型チェックとconvertメソッドを使用するJuliaは、このあいまいさの影響を受けません。

これが、Juliaの正しい解決策が、データ自体に配列のようなセマンティクス（ユニバーサルブロードキャストの場合）とテンソルのようなセマンティクス（可能な収縮の場合）を区別させるべきだと感じる理由です。

私はここでは決して権威ではありませんが、一般的な任意次元のコレクション型（ Array ）がドット積を行う演算子をサポートする必要があるとは思いません。 ドット積は任意の2次元の間にある可能性があり、二項演算子に提供できない追加の引数が必要になるため、この演算子をこのタイプに対して適切に定義することはできません。 同じことがすべての線形代数演算、 inv 、 transposeなどにも当てはまります。

線形代数の数学分野で操作するには、さらに3つのタイプ、 Matrix 、 ColumnVector 、およびRowVectorが必要です。これらのタイプには、すべての通常の線形代数の演算子と関数があります。通常どおりに機能します。

型構造が適切に定義されたので、 MatrixからArray{2} 、 ColumnVectorからArray{1}への暗黙的な変換を追加することで、ユーザーが簡単に変換できるようになります。およびRowVectorからArray{2} （これについては不明）、 Array{2}からMatrix 、およびArray{1}からColumnVector 。

上記の私の提案（https://github.com/JuliaLang/julia/issues/4774#issuecomment-32705055）では、多次元構造の各次元で、ニュートラル（ "collection" / "array"）、アップ（ " column "）、またはdown（" row "）セマンティクス。 あなたが説明しているのは特別な場合だと思います。

この一般的なアプローチの利点は、データまたは空間の多くの次元を使用する計算でも、操作する次元を明示的に指定しなくても、オペレーターに正しいことを実行させることができることです。 少なくともJuliaでは、すべてのインスタンスを呼び出してすべての操作の意味を指定するよりも、タイプパラメータを選択して入力データの意味を一度指定する方がはるかに直感的で読みやすいことに同意すると思います。次元インデックスを与える追加の引数。 意味を異常な方法で途中で変更する必要がある場合でも、完全な次元の一般性を使用して、暗黙的または明示的な変換を使用できます。

@thomasmcoffee私はあなたの提案がとても好きです。 私はDSLで漠然と似たようなものを（ずっと前に、遠く離れて）いくつかの指針（別名個人的な意見）で実装しました：

1. デュアルが別個のものであるという概念は、賢明な自己矛盾のないセマンティクスにとって不可欠です。
2. パラメータ化された演算子（またはそのことについてはデータの外部にあるもの）を使用したテンソル代数のアドホックな強制は、審美的に非常に不快です。

当時私が得た最大の不満（そして彼らは大声でした）は、まさにあなたの三価のセマンティクス（ニュートラルなコレクションの概念を追加する）が解決する種類の不便についてでした。 いいね！ その考えは私には思いもよらなかったが、あなたがそれをそこに出すようになった今、非常に理にかなっている。 本当にそういうシステムを使いたいのですが、実際の仕事を意味します。 ジュリアがこれに対応できたらいいのに！

あなたたちが説明しているように見えるのは、通常のテンソルです。 他の2つのユースケース（コレクションと線形代数）がはるかに一般的であるため、これが標準ライブラリにあることを正当化するのに十分な一般的なユースケースであるとは思えません。 ただし、シームレスに統合できればサポートします。 ベクトル行列の乗算、スカラー配列の乗算、1つの配列の追加を配列の配列に分散するなど、このシステムで一般的な操作がどのように見えるかの例をいくつか挙げてください。

あなたは正しいと思います。 私たちは実際に2つのユースケースについて話している。

線形代数のサブセットは、ほとんどの人があなたとして最も一般的に必要としています
いう。 そこでも、vとv 'の区別を維持することを提唱しています。

私が本当に望んでいるのは（ここに貪欲の開示を挿入）のテンソルです
ファーストクラス（またはクローズ）ステータス...ネイティブ速度に近い（限定的な場合、
線形代数のパフォーマンスと比較して）構文が簡単で、上書きされません
共変性/反変性がデータにエンコードされており、上に押し付けられていないタイピングの問題
オペレーター。 データセマンティクスを定義したら、操作は
ただ働く。 テンソルダックタイピング。

おそらく、テンソルとTDTは、コアではなくパッケージに属しています。
比較的人気のある理由。 しかし、ジュリア宣言のように
独立は言う、ジュリアは貪欲から生まれています。 そしてゴードン・ゲッコーが言うように、
貪欲は良いです。 :)
2014年3月21日午前3時14分、「DavidHagen」 [email protected]は次のように書いています。

あなたたちが説明しているように見えるのは、通常のテンソルです。 私はそれが
標準ライブラリにあることを正当化するのに十分な一般的なユースケース
他の2つのユースケース（コレクションと線形代数）ははるかに多い
一般。 ただし、シームレスに統合できればサポートします。
いくつかの一般的な操作がどのように見えるかの例をいくつか挙げてください
このシステムでは、ベクトル行列の乗算、スカラー配列など
乗算、1つの配列の加算をの配列に分散
配列など？

このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/4774#issuecomment-38262998で表示してください
。

十分に豊富な型族があれば、シームレスな統合は間違いなく達成できると思います。 上記のToivoのhttps://github.com/JuliaLang/julia/issues/4774#issuecomment-32693110を拡張すると、概念的には次のように開始される可能性があります。

immutable AbstractTensorArray{T, N, UPMASK, DOWNMASK} <: AbstractArray{T, N}
    A::AbstractArray{T, N}
end
# where !any(UPMASK & DOWNMASK)

typealias AbstractColumnVector{T} AbstractTensorArray{T, 1, [true], [false]}
typealias AbstractRowVector{T} AbstractTensorArray{T, 1, [false], [true]}
typealias AbstractMatrix{T} AbstractTensorArray{T, 2, [false, true], [true, false]}

（現在、 AbstractMatrix{T}単にAbstractArray{T, 2}エイリアスです。潜在的に、ここでは別の名前を使用できます）

ここから、次の実装は論理的に見えます。

1. 一般化されたtransposeメソッドは、ディメンションと対応するUPMASKおよびDOWNMASKインデックスを再配置した後、UPMASKとDOWNMASKを交換します。 ニュートラル寸法は影響を受けません。
2. AbstractArray{T, N}サブタイプは通常、テンソル演算でデフォルトで対応する交互のAbstractTensorArray{T, N, [..., false, true, false, true], [..., true, false, true, false]}サブタイプに変換されます。 これにより、ベクトルと行列に対するJuliaの特別な配列構文の既存のセマンティクスが保持されます。
3. AbstractTensorArrayのコンストラクターメソッド（たとえば、 array ）は、ニュートラルディメンションを生成するために使用され、他のAbstractTensorArray （またはそれに変換可能なタイプ）を組み合わせて、組み合わせたAbstractTensorArrayを作成できます。ニュートラルなトップレベルのディメンションで

@drhagenの例を検討し

ベクトル行列の乗算、スカラー配列の乗算

c = 1               # Int
v = [1, 2]          # Array{Int, 1}
M = [[1, 2] [3, 4]] # Array{Int, 2}

# scalar-array
c * M               # UNCHANGED: *(Int, Array{Int, 2}) => Array{Int, 2}

# matrix-vector
M * v               # *(Array{Int, 2}, Array{Int, 1}) => *(Matrix{Int}, ColumnVector{Int}) => ColumnVector{Int}

# vector-matrix
v' * M              # transpose(Array{Int, 1}) => transpose(ColumnVector{Int}) => RowVector{Int}
                    # *(RowVector{Int}, Array{Int, 2}) => *(RowVector{Int}, Matrix{Int}) => RowVector{Int}

# (1-array)-(2-array)
v .* M              # UNCHANGED: .*(Array{Int, 1}, Array{Int, 2}) => Array{Int, 2}

（上記のAbstractMatrix定義に対応する定義でMatrixを使用）

1つの配列の追加を配列の配列に分散する

これは、意味的には、ベクトルの配列に1つのベクトルを追加すること、行列の配列に1つの行列を追加することなどを意味します。

# vector-(vector-array)
ws = array([1, 2], [3, 4])
                    # TensorArray{Int, 2, [false, true], [false, false]}
v + ws              # +(Array{Int, 1}, TensorArray{Int, 2, [false, true], [false, false]}) => +(ColumnVector{Int}, TensorArray{Int, 2, [false, true], [false, false]}) => TensorArray{Int, 2, [false, true], [false, false]}
# => array([2, 4], [4, 6])

# array-(vector-array)
u = array(1, 2)     # TensorArray{Int, 1, [false], [false]}
u + ws              # +(TensorArray{Int, 1, [false], [false]}, TensorArray{Int, 2, [false, true], [false, false]}) => TensorArray{Int, 2, [false, true], [false, false]}
# => array([2, 3], [5, 6])
# alternatively:
v .+ ws             # .+(Array{Int, 1}, TensorArray{Int, 2, [false, true], [false, false]}) => TensorArray{Int, 2, [false, true], [false, false]}
# => array([2, 3], [5, 6])
# same effect, but meaning less clear:
v .+ M              # UNCHANGED: .+(Array{Int, 1}, Array{Int, 2}) => Array{Int, 2}
# => [[2, 4] [4, 6]]

# matrix-(matrix-array)
Ns = array([[1, 2] [3, 4]], [[5, 6] [7, 8]])
                    # TensorArray{Int, 2, [false, false, true], [false, true, false]}
M + Ns              # +(Array{Int, 2}, TensorArray{Int, 2, [false, false, true], [false, true, false]}) => +(Matrix{Int}, TensorArray{Int, 2, [false, false, true], [false, true, false]}) => TensorArray{Int, 2, [false, false, true], [false, true, false]}
# => array([[2, 4] [6, 8]], [[6, 8] [10, 12]])

ベクトルvをいくつかの異なる2次形式x'M*w1, x'M*w2, ...でスケーリングする以前の例を考えて、最終結果x'M*w1*v, x'M*w2*v, ... ：

x = v
x' * M * ws * v     # *(RowVector{Int}, Array{Int, 2}) => *(RowVector{Int}, Matrix{Int}) => RowVector{Int}
                    # *(RowVector{Int}, TensorArray{Int, 2, [false, true], [false, false]}) => TensorArray{Int, 1, [false], [false]}
                    # *(TensorArray{Int, 1, [false], [false]}, Array{Int, 1}) => *(TensorArray{Int, 1, [false], [false]}, ColumnVector{Int}) => TensorArray{Int, 1, [false, true], [false, false]}
# => array([27, 54], [59, 118])

この概念的な実装では、 AbstractArrayはそのままにしておくと想定しているため、 AbstractTensorArrayは型階層内に独自の「スペース」を形成します。 AbstractArrayファミリー全体が単にAbstractTensorArrayに置き換えられた場合、状況は単純化される可能性がありますが、それは別の議論です。

量子物理学の何かのパッケージのコンテキストでは、私は自分のテンソル型（実際には複数）を定義することで遊んでいます。 最初は、インデックスが2つのフレーバー（アップとダウン、着信と発信、共変と反変、ただし、それを呼び出したい）で提供されるという概念もありました。この情報は、タイプのフィールドまたはタイプパラメータ。 しばらくして、これは非常に面倒だと思いました。 テンソルのインデックスをベクトル空間（とにかくすでに行っていた）に関連付けるだけで、このベクトル空間に異なるデュアルを持たせる方がはるかに簡単です。 実際には、ベクトル空間とは、空間の次元とそれがデュアルであるかどうかをラップする単純なジュリア型を意味します。 テンソルインデックスが法線ベクトル空間に関連付けられている場合はアップインデックスであり、デュアルインデックスに関連付けられている場合はダウンインデックスです。 区別のないテンソル/配列を使用したい場合は、通常のベクトル空間とそのデュアルを区別しない別のベクトル空間タイプを定義するだけです。

この提案では、互いに二重であるベクトル空間に関連付けられているテンソルインデックスのみを縮小できます。 ctranspose（=エルミート共役）は、すべてのインデックスのベクトル空間をそのデュアルにマップします（行列の場合はインデックスの順列、および高次テンソルの推奨定義とともに）など。

もちろん、通常の転置と複素共役は、この設定では実際には十分に定義されていません（つまり、これらは基本的に独立した概念ではありません）

最小限、次のようになります。

immutable Space
    dim::Int
    dual::Bool
end
Space(dim::Int)=Space(dim,false) # assume normal vector space by default
dual(s::Space)=Space(s.dim,!s.dual)

matrix=Tensor((Space(3),dual(Space(5))))
# size is no longer sufficient to characterise the tensor and needs to be replaced by space
space(matrix) # returns (Space(3),dual(Space(5))) 
space(matrix') # returns (Space(5),dual(Space(3)))

もちろん、Spaceを絶えず書き込む必要がないように、いくつかの構文を発明することもできます。 アップインデックスとダウンインデックスを区別しないテンソルなどを作成するために、dual（s）== sの異なるスペースタイプを作成できます。 しかしもちろん、すべてを壊さずにこれをJuliaの標準配列型に組み込む方法はありません...

工学/物理学でテンソルがどのように使用されるかと、数学ソフトウェアプログラムでテンソルがどのように処理されるかとの間に密接な関係がないのはなぜかといつも思っていました。 このトピックに関する興味深いスタック交換の会話を見つけました... http：//math.stackexchange.com/questions/412423/differences-between-a-matrix-and-a-tensor。 ここでも、良い参考記事でした。
http://www.mat.univie.ac.at/~neum/physfaq/topics/tensors

私は毎日の科学計算にMatlabをよく使用していますが、Juliaの初心者です。 ここで、高次元の配列の乗算と転置、または他の同様の配列操作について多くの議論があることに気付きました。 http://www.mathworks.com/matlabcentral/fileexchange/8773-multiple-matrix-multiplications--with-array-expansion-enabledを確認することをお勧めし

これは基本的に、 @ drhagenが以前の投稿で述べたものと同様の構文に従います。たとえば、配列AとBの間の積のarray_product（A、B、inner_A_dim = [1、2]、inner_B_dim = [3、4]）与えられた内部寸法。

これは、選択したいくつかの次元に乗算または転置演算を適用できる1つのMatlabパッケージです。 パッケージには、Matlabでこれらの操作を実装する方法に関するマニュアルがありますが、数学理論は他の言語にも適用されるはずです。 彼らのアイデアは、Forループの使用を避け、主に配列の再形成などに依存することによって、配列操作を実装することです。 したがって、Matlabでは非常に高速です。 ジュリアがベクトル化された操作とベクトル化されていない操作のどちらに似ているかはわかりません（後者のようです）。 コアがサポートしていれば、ベクトル化された演算は高次元の配列演算にとって有利だと思います。 この段階で、この種の配列操作を真摯に検討する必要があるかもしれません。

参考までに：MatlabでのINV操作用の別の同様の実装は次のとおりです： http ：

また、2005年にMatlabアレイ操作サポートパッケージがリリースされた後、ダウンロード記録は今日まで高いレベルで維持されていることにも注意してください。 私の実際の経験と同様に、配列演算は物理学やその他の分野で非常に頻繁に使用されます。 ジュリアが任意のサイズの配列を操作するための同様の機能を持っていれば、ゲームは非常に興味深いものになるでしょう！

@alanedelmanが提案したトップへの解決策に対する別の投票がここにあります。 これがやる気を起こさせる例です。

現在、行スライスは2次元配列であり、列スライスは1次元配列です。 これは奇妙に非対称で醜いです：

julia> A = randn(4,4)
4x4 Array{Float64,2}:
  2.12422    0.317163   1.32883    0.967186
 -1.0433     1.44236   -0.822905  -0.130768
 -0.382788  -1.16978   -0.19184   -1.15773
 -1.2865     1.21368   -0.747717  -0.66303

julia> x = A[:,1]
4-element Array{Float64,1}:
  2.12422
 -1.0433
 -0.382788
 -1.2865

julia> y = A[1,:]
1x4 Array{Float64,2}:
 2.12422  0.317163  1.32883  0.967186

特に、行に列を掛けて数値を抽出するには、次のようなひどく醜い操作を行う必要があります。

julia> dot(y[:],x)
2.4284575954571106
julia> (y*x)[1]
2.42845759545711

'*を特別な演算子にしない限り、これは首尾一貫した提案ではありません。これはかなり疑わしいため、 x'*yと(x')*yは同じ意味ではありません。 さらに、それは乗算を非連想にします。

x_y 'とy'_xの難しさを理解しています。 治療する方が良いかもしれません
内積と外積を別々の操作として、たとえばdot（）を使用します。 （おそらく
cdotも使用していますか？）

しかし、最初に沿ってスライスを持つことを支持する議論は何ですか
次元は、それに沿ったスライスとは次元が異なるオブジェクトを返します
二次元？ 一貫性を保つために、スライスするたびに、
結果のオブジェクトの寸法は1つ減らす必要があります。

20:17の水曜日、2014年7月16日には、ステファンKarpinski [email protected]
書きました：

'*を特別な演算子にしない限り、一貫した提案ではありません。
それ以来、x'_yと（x '）_ yは同じことを意味しないので、かなり疑わしいです。
さらに、それは乗算を非連想にします。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-49254346 。

マドレーヌ・ウデル
計算および数学工学の博士号候補者
スタンフォード大学
www.stanford.edu/~udell

@madeleineudell 、私はあなたに同意しますが、それは別の問題です。＃5949を参照してください。 その問題は解決されたようですが、明確な合意や結論があったことを覚えていません。

配列ビューに切り替えると、それらの方向を簡単に探索できるようになります。 特に、 slice(A, i, :)と言うと、希望する動作が得られます。 （今はそうしていますが、より遅いタイプのSubArrayを導入するという犠牲を払っています。）

純粋に数学的な観点から、ここで提示されるすべての問題は、配列が意味するものとベクトル/テンソル/行列が意味するものの混同（およびそれらの間の混乱）から生じます。 配列は、概念的には単なるリスト（または、n-dim配列の場合はリストのリスト）です。 そのため、配列の乗算、転置などの操作の自然な仕様はありません。一方、並べ替え、要素ごとの操作、軸固有の操作（平均、中央値など）などの関数は意味があり、で一意に定義できます。当然のことながら、ドット積などの操作はできません。

上記のように、ベクトルとテンソルは幾何学的オブジェクトであり、配列を使用してそれらを表現することは可能ですが、これらの表現には、それらが表す数学的オブジェクトと同じ豊富な構造は含まれていません。 1次元配列の転置は何もしません。 ベクトルの転置はその双対です。 2次元配列の転置は、その次元の順列として一意かつ自然に定義できますが、これは一般にテンソルには当てはまりません。自然な場合はランク（1,1）テンソル（別名、行列）に当てはまりますが、ランク（2,0）テンソルはランク（0,2）テンソルに転置します。 この場合も、テンソルを配列として扱うことにより、テンソルをテンソルにする幾何学的情報が失われます。

これは、内積などの演算を定義するときに重要です。 内積には特定の幾何学的意味（2番目のベクトルによって定義される双対空間への1つのベクトルの射影）があるため、内積の一貫した定義には、ベクトルに含まれる幾何学的情報の保存が必要です。 特定の仮定を使用すると、配列を使用でき、ユースケースの大部分をカバーできる可能性がありますが、これらの仮定は（このスレッドのさまざまな提案に見られるように）厄介であり、テンソルのより豊富な構造を必要とする人にとっては実際には困難になります。

したがって、これは、より豊富なAbstractTensorタイプを含めるというthomasmcoffeeの提案に賛成する強い投票だと考えてください。 私の個人的な好みは、転置やドット積などの操作が配列に対しても定義されていないことですが、ほとんどの人がその見解を共有しないと思うので、少なくとも必要に応じて真のテンソルを作成する機能が必要です。

この観点の実際的な意味は、配列はテンソルのサブセットで識別されるべきであり、1-d配列を転置するとDualVectorまたはおそらくエラーが発生するはずであるということのようです。 私の見解では、これは複素数を与える実数の演算に類似しています。

私の見解では、（多次元の）データコンテナである一般的なAbstractArrayファミリは、技術的なプログラミング言語の不可欠な部分となるのに十分なほど一般的です。 厳密な数学的規則に従うテンソルは、私が心から気にかけているとしても、専用パッケージの良いオブジェクトです。 実際、私はhttps://github.com/Jutho/TensorToolbox.jlの@jdbatesで指定されたます。 これまでのところ文書化されておらず、ほとんどテストされていません。 私は量子多体物理学で個人的に必要なもののためにそれを書きましたが、テンソルを扱うことに関心のある数学者や物理学者のより大きなコミュニティに役立つように十分に一般的で拡張可能な方法で構築されていることを願っています。

詳細を説明します（JuliaQuantumフォーラムからコピー）：JuliaのAbstractArrayタイプに依存しない、テンソルの新しいタイプ階層を定義することにしました（ただし、基本的なTensorはArrayの単なるラッパーです）。 このタイプ階層は、もう少し正式な方法で機能するはずです。 テンソルインデックスはベクトル空間（以降、インデックススペースと呼びます）に関連付けられます。テンソルインデックスが関連付けられているベクトル空間のタイプがデュアルと異なる場合、これは共変インデックスと反変インデックスを区別するテンソルに対応します。

したがって、パッケージの最初の部分は、ベクトル空間を定義するための抽象的な部分です。ここで、Juliaオブジェクトの型階層をベクトル空間の数学的階層に一致させます。 一般ベクトル空間Vには、V上の一般線形群の表現論に対応する、V自体（基本表現）、conj（V）、dual（V）、dual（conj（V））の4種類があります。 実数ベクトル空間の場合、conj（V）= Vであり、反変ベクトルと共変ベクトルに対応するVとdual（V）のみがあります。 次に、内積空間があり、階層の最上位にはユークリッド空間があります。これは、標準のユークリッド内積（つまり直交基底）を持つ内積空間です。 物理学では、さまざまなセクターに分解されるベクトル空間について考えることも役立ちます。つまり、対称作用の既約表現などによって等級付けされます。

テンソルは、いくつかの基本ベクトル空間のテンソル積（の部分空間）に存在するオブジェクトです。 ただし、インデックス空間のテンソル積空間に存在するオブジェクトである標準テンソルとは別に、たとえば、irrepsによって等級付けされた空間のテンソル積の不変セクター、の対称または非対称部分空間に存在するテンソルを構築できます。同一空間のテンソル積、...インデックス空間としてフェルミオンベクトル空間を持つことができます。これは、テンソルインデックスの順列が、パリティセクターなどに応じて特定の符号変化を引き起こすことを意味します。

次に、テンソルで定義された特定の操作があり、その中で最も重要なのはテンソルの縮約ですが、直交因数分解（特異値分解）などもあります。最後に、あるテンソルを別のテンソルにマッピングする線形マップが必要です。 それらは、通常、それらを行列として完全にエンコードするのではなく、反復法（Lanczosなど）で使用するために行列ベクトル積を効率的に計算できる方法で、特別なタイプに値します。 これまでの私の2つの既存のパッケージ（TensorOperations.jlとLinearMaps.jl）は、標準の配列に対してこの機能を実装しています。構築中のテンソルツールボックスは、新しいAbstractTensor階層に対してそれらをオーバーロード/再定義します。

このパッケージが十分に一般的であり、より広い物理学/数学コミュニティにも役立つことを願っています。 たとえば、多様体を操作するためのパッケージを作成する誰かがやってきた場合、彼はTangentSpaceベクトル空間を抽象InnerProductSpaceの部分空間として定義し、すぐにいくつかの接線空間と余接空間のテンソル積に存在するテンソルを作成できます。 実際、私はベクトル空間を定義するための部分を別のパッケージに分割することを考えています。それは数学的構造/オブジェクトを定義するためのパッケージに成長する可能性があります。

最後に、標準のジュリアとの相互運用が呼び出しから来tensor標準でArray型のオブジェクトにそれをラップした、 Tensor型のスペースに関連付けられているインデックス付きCartesianSpace 。 これは、ユークリッド積を使用した標準の実ベクトル空間R ^ nであり、共変指数と反変指数の区別はありません。 これは、標準のJuliaArrayが何であるかを最もよく表していると思います。

@JeffBezanson 、私は配列をテンソルのサブセットとして扱うことに関して曖昧です。 その方法で情報が失われることはありませんが、同時に、配列には複数の可能な解釈があり、テンソルの解釈が常に（または通常でも）意味をなすとは限りません。 画像について考えてみましょう。画像は、（通常は2d）多様体上のベクトル値フィールドと考えることができます。 そのフィールドを長方形のグリッドに制限すると、当然、3D配列を使用して表現したい構造が得られます。 ただし、実際には、これはグリッドポイントの空間から{R、G、B}ベクトル空間への単なるマッピングであるため、最初の2つの次元（グリッドのxラベルとyラベル）の幾何学的意味は3次元の幾何学的意味（実際にはベクトル）。

私は、テンソル力学を別のパッケージに分割するという@Juthoの提案に反対していません。 彼はおそらく、完全なテンソルメカニズムを必要とするユーザーの数が、単純な配列操作を必要とするユーザーの数よりもはるかに少ないことは正しいでしょう。 ここで私たちが本当に尋ねようとしている質問は、「線形代数はどの領域に分類されるべきか」です。

線形代数の機構は、テンソル代数の機構の実質的なサブセットであり、少なくとも私の考えでは、後者を実装せずに前者を実装することは意味がありません。 v'Mのような演算は、共変ベクトルと反変ベクトルの概念がある場合、より簡潔かつ一貫して表されますが、それはすでに一般的なテンソル演算への道のほとんどを私たちにもたらします。

これは、複素数を返す実数の演算と概念的に似ていることに同意します。

画像について考えてみましょう。画像は、（通常は2d）多様体上のベクトル値フィールドと考えることができます。 そのフィールドを長方形のグリッドに制限すると、当然、3D配列を使用して表現したい構造が得られます。 ただし、実際には、これはグリッドポイントの空間から{R、G、B}ベクトル空間への単なるマッピングであるため、最初の2つの次元（グリッドのxラベルとyラベル）の幾何学的意味は3次元の幾何学的意味（実際にはベクトル）。

これはメッセージ全体に対処したり、それを取り除いたりするものではありませんが、 https：//github.com/timholy/Images.jl/pull/135は、画像に対するこのアイデアの実装に向けて取り組んでいます。 これにより、プロジェクトで使用したいと考えている色構造テンソルも簡単に処理できるようになることを願っています。

2014年8月23日には、午前20時36分で、jdbates [email protected]書きました：

@JeffBezanson 、私は配列をテンソルのサブセットとして扱うことに関して曖昧です。 その方法で情報が失われることはありませんが、同時に、画像には複数の可能な解釈があり、テンソルの解釈が常に（または通常でも）意味をなすとは限りません。 画像について考えてみましょう。画像は、（通常は2d）多様体上のベクトル値フィールドと考えることができます。 そのフィールドを長方形のグリッドに制限すると、当然、3D配列を使用して表現したい構造が得られます。 ただし、実際には、これはグリッドポイントの空間から{R、G、B}ベクトル空間への単なるマッピングであるため、最初の2つの次元（グリッドのxラベルとyラベル）の幾何学的意味は3次元の幾何学的意味（実際にはベクトル）。

テンソルが配列に取って代わるものではないことに同意します。 上記のこの例は、実際には異なる数学的構造（つまり、ベクトルバンドルまたはより一般的にはテンソルバンドル）であり、その表現は、多様体座標のグリッドとベクトル空間部分の基底を選択することによって多次元配列として与えることもできます。 したがって、実際には、座標非依存/基底非依存の方法で明確に定義されているが、（座標系または基底を選択した後）多次元配列として表すことができるさまざまな数学的オブジェクト/構造を持つことができます。 したがって、多次元配列は確かにテンソルの表現に限定されません。 すべてのテンソルが多次元配列を使用した便利な表現を持っているわけではないため、逆も失敗します。 これは、テンソル積空間に含まれるベクトル空間の個々の基底ベクトルのすべての可能な組み合わせの直接積を取ることによって得られる、積基底と呼ばれる特定の基底を使用する場合にのみ当てはまります。 場合によっては、たとえば、テンソル積空間の対称性不変部分空間でテンソルを使用する場合、そのような表現はもはや不可能であり、テンソルがちょうど表現される完全な空間に対して異なる基底を定義する必要があります。数字の長い一次元リスト。

私は、テンソル力学を別のパッケージに分割するという@Juthoの提案に反対していません。 彼はおそらく、完全なテンソルメカニズムを必要とするユーザーの数が、単純な配列操作を必要とするユーザーの数よりもはるかに少ないことは正しいでしょう。 ここで私たちが本当に尋ねようとしている質問は、「線形代数はどの領域に分類されるべきか」です。

線形代数の機構は、テンソル代数の機構の実質的なサブセットであり、少なくとも私の考えでは、後者を実装せずに前者を実装することは意味がありません。 v'Mのような演算は、共変ベクトルと反変ベクトルの概念がある場合、より簡潔かつ一貫して表されますが、それはすでに一般的なテンソル演算への道のほとんどを私たちにもたらします。

これは、複素数を返す実数の演算と概念的に似ていることに同意します。

—
このメールに直接返信するか、GitHubで表示してください。

配列には複数の可能な解釈があり、テンソルの解釈は常に（または通常でも）意味があるとは限りません。 画像について考えてみましょう。画像は、（通常は2d）多様体上のベクトル値フィールドと考えることができます。 そのフィールドを長方形のグリッドに制限すると、当然、3D配列を使用して表現したい構造が得られます。 ただし、実際には、これはグリッドポイントの空間から{R、G、B}ベクトル空間への単なるマッピングであるため、最初の2つの次元（グリッドのxラベルとyラベル）の幾何学的意味は3次元の幾何学的意味（実際にはベクトル）。

配列のようなものとテンソルの両方を許可することで、 https： //github.com/JuliaLang/julia/issues/4774#issuecomment-38333295の概念的なAbstractTensorArray提案でキャプチャしようとしたのはまさにこの種の区別

AbstractTensorArray{Uint8, 3, [false, true, false], [true, false, false]}

そのため、x、y、およびRGBの寸法は、それぞれ「下」、「上」、および「中立」になります。 幾何学的操作（たとえば、アフィン変換）は、配列のような方法でRGB値をマッピングしながら、テンソルのような方法でグリッド座標の次元を処理できます。 （後でRGB値を幾何学的に扱いたい場合は、その目的のためにマスクを明示的に変更する必要がありますが、（a）2つの異なるフレーバーの幾何学的操作がの異なる部分空間に適用されることはあまり一般的ではないと思います同じデータテーブル、および（b）この状況では、明示的な変換はおそらくコードの明快さを_改善_します。）

@Juthoが言及している共役表現については考慮していません

ここで私たちが本当に尋ねようとしている質問は、「線形代数はどの領域に分類されるべきか」です。

配列のような操作とテンソルのような操作がどのように連携するかについて設計が決まったら、線形代数のエンティティを特別な場合（上記で使用したエイリアスなど）で定義できるため、純粋な線形代数のユーザーは気付かないことがあります。必要になるまで、一般化されたテンソル階層全体（ただし、必要に応じて書き直す必要はありません）。 したがって、すべてをBaseに配置しても問題は発生しません（おそらく膨張を除く）。

そのため、x、y、およびRGBの寸法は、それぞれ「下」、「上」、および「中立」になります。 幾何学的操作（たとえば、アフィン変換）は、配列のような方法でRGB値をマッピングしながら、テンソルのような方法でグリッド座標の次元を処理できます。 （後でRGB値を幾何学的に扱いたい場合は、その目的のためにマスクを明示的に変更する必要がありますが、（a）2つの異なるフレーバーの幾何学的操作がの異なる部分空間に適用されることはあまり一般的ではないと思います同じデータテーブル、および（b）この状況では、明示的な変換によってコードの明確さが向上する可能性があります。）

ここで何かを混ぜていると思います。 上記の説明では、x座標とy座標は、必ずしも平坦な空間ではなく、任意の湾曲した多様体上の座標に対応できるため、ベクトル空間の解釈を持たないことが実際に説明されました。 ベクトル解釈が与えられたのはRGB次元でしたが、色空間もかなり湾曲していることを覚えているようですが（画像処理に適切な背景がないため）、これも実際には最良の選択ではない可能性があります。 また、定義域（xとy）がベクトル空間を形成している場合でも、なぜxとyが上下するのでしょうか、それともこれは単なる表記例でしたか？

とにかく、私はTensorToolbox.jlから始めて、共変および反変のインデックスをある種のパラメーターまたはマスクとして示しましたが、これはすぐに完全な悪夢になります。そのため、すべてのテンソルが何らかのベクトル空間の要素である表現に切り替えました。 、および操作を実行するには、配列を使用して操作を実行するときにサイズが一致することを確認する必要があるのと同じように、スペースが一致することを確認する必要があります。

x座標とy座標は、ベクトル空間の解釈を実行しませんでした

申し訳ありませんが、「長方形グリッド」を読み過ぎました---

すべてのテンソルは、あるベクトル空間の要素です。

いいアイデアのようです---ユーザーにとってどのように機能するかの例をいくつか見てみたいと思います（コードをあまり読んでいませんでした）。

この問題について新しい提案があります。

（1）APLスタイルのスライス。

size(A[i_1, ..., i_n]) == tuple(size(i_1)..., ..., size(i_n)...)

特に、これは「シングルトンスライス」、つまりインデックスがスカラーまたはゼロ次元のスライスが常に削除され、 M[1,:]とM[:,1]が両方ともベクトルであり、一方がベクトルではないことを意味します。もう1つは行行列、またはその他のそのような区別です。

（2）ベクトルと行列のTransposeとConjTransposeラッパータイプを導入します。 言い換えれば、次のようなものです。

immutable Transpose{T,n,A<:AbstractArray} <: AbstractArray{T,n}
    array::A
end
Transpose{T,n}(a::AbstractArray{T,n}) = Transpose{T,n,typeof(a)}(a)

そして、これらをベクトルや行列の場合と同じように機能させるためのすべての適切な方法。 一般的な転置が任意の次元に対して何を意味するのかが明確でないため、ベクトルと行列に対してのみ機能するように制限することをお勧めします（ただし、次元を逆にするだけでも魅力的です）。 あなたが書くときa'あなたが得るConjTranspose(a)と同様にv.'生成Transpose(a) 。

（3）次のような（共役）転置ベクトルおよび行列のさまざまな特殊な方法を定義します。

*(v::Transpose{T,1}, w::AbstractVector) = dot(v.array,w)
*(v::AbstractVector, w::Transpose{T,1}) = [ v[i]*w[j] for i=1:length(v), j=1:length(w) ]

など、すべての恐ろしいAt_mul_B関数を置き換え、特別な解析を怠惰な（共役）転置構造に置き換えた後、 TransposeおよびConjTransposeタイプにディスパッチします。

（4）ブロードキャスト操作を、引数が同じ次元数のスカラーまたは配列である場合に制限します。 したがって、現在示されているように機能する以下は失敗します。

julia> M = rand(3,4);

julia> M./M[1,:]
3x4 Array{Float64,2}:
 1.0       1.0       1.0      1.0
 0.516884  0.675712  2.11216  9.0797
 1.00641   0.726229  2.48336  4.38751

julia> M./M[:,1]
3x4 Array{Float64,2}:
 1.0  0.891557  0.561464  0.103968
 1.0  1.16552   2.29433   1.82633
 1.0  0.643353  1.38544   0.453257

代わりに、次のようなことを行う必要があります。

julia> M./M[[1],:]
3x4 Array{Float64,2}:
 1.0       1.0       1.0      1.0
 0.516884  0.675712  2.11216  9.0797
 1.00641   0.726229  2.48336  4.38751

julia> M./M[:,[1]]
3x4 Array{Float64,2}:
 1.0  0.891557  0.561464  0.103968
 1.0  1.16552   2.29433   1.82633
 1.0  0.643353  1.38544   0.453257

この提案は、私たちが現在抱えている主要な問題をすべて解決すると信じています。

1. 対称的なスライス動作–トレーリング寸法は特別ではなくなりました。
2. v'' === v 。
3. v' == v 。
4. v'wは、 vとw内積です。特に、これは1要素のベクトルではなく、スカラーです。
5. v*w'は、 vとwの外積です。
6. M*vはベクトルです。
7. M*v'はエラーです。
8. v'*Mは転置ベクトルです。
9. v*Mはエラーです。
10. At_mul_B演算子と特別な構文解析はなくなります。

：+1：すべてに。 ＃6837で2と3の作業をしましたが、完了しませんでした。 @simonbyrneもそれを調べました。

+1も。 それは至る所で非常に一貫した振る舞いを提供するように聞こえます。

この提案の唯一の本当に破壊的な部分は、実際にはM[1,:]が明示的に水平な行行列ではなく、暗黙的に垂直なベクトルであるということです。 それ以外の場合は、実際には非常にスムーズで中断のない一連の変更です（1つは期待できます）。 （私にとって）主なひらめきは、APLスライス動作を怠惰な転置と組み合わせることができるということでした。 賛同を得れば、計画を立てて作業を分割することができます。 怠惰な転置とステージングされた関数によって、コードの削減と簡素化が可能になることを本当に望んでいます。

はい、お願いします！ テンソル転置は、デフォルトとして薄暗い値を逆にして、ユーザー定義の順列をおそらく許可するはずです。

テンソル転置は、デフォルトとして薄暗い値を逆にして、ユーザー定義の順列をおそらく許可するはずです。

型が少し複雑になるようです。おそらく、任意の遅延次元の順列を許可するPermuteDims型を使用できます。

@Stefan ：これはベクトルと2
代数。 いくつかの課題：

1. 多次元配列の場合について：次元のある配列Aの場合
   （i_1、i_2、...、i_n）、[i_2、i_3]に転置を適用したい場合
   次元-または、[i_2、i_4]次元のハッシュですら。 あなたはそれをすることができます
   転置の新しい定義？
2. シングルトン次元について：シングルトンスライスは次のようになります。
   意図的に残しました。 ジュリアはこのシングルトン次元を維持する必要があります
   計算？ たとえば、ベクトルを配列Vとして定義した場合、
   （2,1）の次元であり、転置に行列Aを乗算したい
   次元（2、3、4）。 次の次元でv '* Aの結果を生成できますか
   （1,3,4）？

14:31の木、2014年10月16日には、ステファンKarpinski [email protected]
書きました：

唯一の破壊的なのは、実際にはM [1 、：]が（垂直）ベクトルであるということです。
行行列ではなく。 そうでなければ、それは実際にはかなりスムーズです、
中断を伴わない一連の変更（1つの希望）。 （私にとって）主なひらめきは
そのAPLスライス動作は、レイジートランスポーズと組み合わせることができます。 取得した場合
バイイン、私たちは計画を考え出し、仕事を分割することができます。 心から願う
その怠惰な転置とステージングされた関数は、いくつかのコード削減を可能にし、
簡素化。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-59425385 。

Re 2＆3：大まかな突き刺しがあったので、ベクトル転置はAbstractVectorサブタイプであってはならないという結論に達しました。そうしないと、すべてが乱雑になります（＃6837の説明を参照）。 最も正しい方法は、 Transpose{T,A} <: AbstractMatrix{T}と、別のCovectorタイプ（+ Conjugateバリアント）を使用することだと思います。

私が遭遇した他の重要な問題は、特定の行列タイプ、その転置、またはその共役転置でディスパッチしたいということです。 残念ながら、既存のタイプの機械でこれを表現する方法を思い付くことができませんでした（このメーリングリストの説明を参照してください）。 これがなければ、3x3以上の可能な引数の組み合わせで多くの@evalが発生するのではないかと心配しています。

@simonbyrne 、実装の経験を

私は（あまり公開されていないフォーラムで、おそらくここで簡単に言及します）、SubArrayが使用できるインデックスのタイプを拡張することにより、すべてのシェーピングを_内部的に_処理することを代替案として指摘しました。 特に、親配列がVector場合でも、SubArrayに転置された形状を与える「転置範囲」タイプを持つことができます。 （SubArrayの実装方法に慣れていない場合は、https：//github.com/JuliaLang/julia/blob/d4cab1dd127a6e13deae5652872365653a5f4010/base/subarray.jl#L5-L9を参照してください。）

この代替戦略が人生を楽にするのか、それとも困難にするのかはわかりません。 これにより、外部に面するタイプの数が減ります。つまり、必要なメソッドが少なくなる可能性があります。 （ ImagesのColor遷移のために不足しているメソッドを_まだ_埋めている人として、これは良いことのように思えます。）一方、便利な三角ディスパッチがない場合は、 @simonbyrneによって発生する問題を悪化させる可能性がある、選択的なメソッドを作成するのがやや厄介になります。

どんな洞察も大歓迎です。

そのような詳細は別として、私は@StefanKarpinskiの提案の形が好きです。 私はAPLスタイルのインデックス作成に夢中になっているわけではありませんが、全体として、現在のMatlabから派生したルールよりも優れた選択だと思います。

2つの考え：

• A[[2], :]などのインデックス作成が慣用的になった場合、単一のインデックス2をラップするためだけにベクトルを作成する必要があるのは少し無駄に思えます。 同じこと、または同様のことに対してA[(2,), :]を許可することを検討する必要がありますか？ 単一の要素範囲で問題ないと思いますが、 [2]とほぼ同じくらい便利な構文があると便利です。
• ブロードキャストを行うために一致する次元数が必要な場合は、配列にシングルトン次元を追加する簡単な方法が必要です。たとえば、numpyのnewaxisインデックスのようなものです。

セミコロンを使用したインデックス作成（ A[2;:] ）は、結果が常にAと同じ次元数になる別のインデックス作成モードになる可能性があることを提案しようと考えていました。つまり、シングルトンを削除せず、ランクが複数あるものはすべてエラーです。 簡単にするためにコア提案からそれを除外することにしましたが、そのようなものは持っているのは良いことのように思えます。

@simonbyrneによって表明された懸念を見ることができます。 ただし、原則として、コベクトルは、異なるベクトル空間、つまり双対空間に存在する単なるベクトルでもあります。 したがって、 TransposeまたはCovectorタイプをAbstractArrayサブタイプではないようにすることも、やや不快に感じます。 考えられる解決策は、大きな重大な変更であり、おそらく考慮されないでしょう（しかし、とにかく言及したかったのですが） AbstractArrayファミリー全体に追加の型パラメーターtransを与えることです。 、値は:N 、 :Tまたは:Cます。 ベクトルを数値の1次元リストであると想定するすべてのメソッドの場合、この最終パラメーターの異なる値を区別する必要がないため、対応するメソッド定義を現在のままにすることができます。

N> 2のN次元配列には、さまざまなオプションがあります。 transposeでエラーが発生し、 AbstractArray{3,Float64,trans}タイプのオブジェクトを実際に作成することはできません。 trans!=:N 、または:T単に行メジャーを意味しますまた、一般的な配列のtransposeは、すべての次元を逆にする効果があります。 後者は、ペンローズのグラフ記法を使用する人々にも受け入れられている慣習だと思います（転置については説明されていませんが、http：//en.wikipedia.org/wiki/Penrose_graphical_notationを参照してください。また、Cvitanovićによる引用本も参照してください）。

transposeでサポートされている任意のインデックス順列の役割は実際にはわかりません。そのためのpermutedimsがあり、改良されたSubArrayを使用した怠惰なアプローチかもしれません。 さらに、この問題の主な動機はA_mul_B動物園を単純化することであり、高次のテンソルの縮約はとにかく通常の乗算​​ではサポートされていません（サポートされるべきではありません）。

このアプローチに関連して、私がまだ考えていないいくつかの新しい問題があると確信しています。

ここでディスパッチ問題の合理的な解決策を見つけたと思い

@Juthoの提案は面白そうだし、検討する価値があると思う。 残念ながら、これらを評価する唯一の実際の方法は、それらを実装しようとすることです。

@toivoh 、

• A[2:2,:]もディメンションを保持し、割り当てや新しい構文は必要ありません。
• newaxisようなものは非常に実行可能のようです。 実際、＃8501のアーキテクチャでは、インデックスを作成することで直接ブロードキャストを作成できるようです。ユーザーがそのスロットに入力する値に関係なく、常に1に解決されるインデックスタイプを使用してください。

2:2は、 2だけでなく、インデックスに長い式がある場合の繰り返しです。 ただし、もちろん、インデックスから範囲を作成するために、いつでも独自の関数を定義できます。

非常に良い提案：+1:。

v' == v必要な理由を思い出してください。

それは本当に必要ではありませんが、（有限次元の）ベクトル空間の双対はそれと同型であるため、それは一種の素晴らしいことです。

さらに強く、ジュリアの配列は共変指数と反変指数を区別しないため、これをデカルト空間（ユークリッド距離=単位行列=クロネッカーデルタ）のベクトルと考えるのが理にかなっています。実際、双対空間は自然に存在します。同形。

v '== vが必要かどうかはわかりませんが、これはかなり直交していると思います。
残り。 列行列とベクトルが等しい場合、それらを比較する必要がありますか？
等しい要素がありますか？

次元数が異なるため、実際には別の問題です。

特に、この提案では、ベクトルと列行列の間の識別が効果的に削除されます。これは、行列を水平または垂直にスライスすると、どちらの方法でもベクトルが得られるためです。 以前は、末尾のシングルトンディメンションを無視したり、実際よりも多いふりをしたりすることができました。 ベクトルは配列の任意のスライスから取得できるため、これを行うことはもはや良い考えではありません。

末尾のシングルトン次元を追加することで、1次元から2次元までのconvert意味がありますか？

この提案では、それはもはや良い考えではないかもしれないと思います。 しかし、おそらくベクトルは依然として列のように動作し、コベクトルは行のように動作するためです。

＃8416で私が指摘したことの1つは、 sparsevecが現在単一列のCSCマトリックスとして乱雑に偽造されていることです。 適切な1-dスパースベクトルタイプが実装されると、スパースはこれにかなりうまく適合するはずです（これは、一般的なNd COOタイプの最も単純な便利なケースとして分類され、記述する必要があります）。

これをすべて取り入れてください。それで、次はうまくいきませんか？

A [1 、：] * A * A [：、1]＃行列からの行*行列*行列からの列???

あなたが書いた

v'wはvとwの内積です。特に、これはスカラーであり、1要素のベクトルではありません。

また、v '* wはスカラーですか？

dot（x、y）が（1、...、1、m、1、...、1）とである任意の2つのアイテムを取るというアイデアが好きです
何があってもドット積を返します。 しかし、私はx * yがこの意味でdot（x、y）を与えたくありません
xが共ベクトルで、yがベクトルでない限り。

これがそんなにホットなアイデアかどうかはわかりませんが、多分それは大丈夫でしょう
A [：、1,1]はベクトルであり、A [1、：、1]またはA [：、1 、：]は共ベクトルでした。
ベクトルの次元に沿って追跡する方が良いと感じます-スロット、あなたが
標準の線形代数でテンソルを収縮することができます
1（行ベクトル）と2列ベクトル。

私の見解では、この問題で以前に対処した2つの主要な課題は次のとおりです。

（A）多次元データを操作するときに、テンソルセマンティクス（収縮の場合）と配列セマンティクス（ブロードキャストの場合）を区別する方法。
（B）より高い次元に一般化する一貫したフレームワーク内に明白で便利な線形代数を埋め込む方法。

この提案がこれらの問題のいずれかをどのように扱っているかは私にはわかりません。 私の知る限り、（A）を達成するには、（現在の機能と同様に）アドホックなユーザー操作が必要です。 怠惰なラッパーを使用して（B）に対処するには、@ timholyによって提案されたSubArray拡張機能のようなものが必要になります。その時点で、それは先ほど説明したマスキングアプローチの怠惰なバージョンになります。 同様のレイジーメカニズム（ Listラッパータイプなど）を使用して（A）の追加サポートを提供することを想像できますが、これらすべての場合において、レイジーはオプションの戦略である必要があるように思われます。

「高次テンソルの縮約は、とにかく通常の乗算​​ではサポートされない（そしてサポートされるべきではない）」という@Juthoの見解を共有する人の数はわかりませんが、これ以上異議を唱えることはできません。私は通常のエンジニアリングと見なすものだけを実行します。数学、そして私はいつもそれらを必要としています。 MathematicaやNumPyのような現在の言語にはこの点で設計上の制限がありますが（私が上で議論したように）、少なくともサポートされています！ たとえば、単純な数値解法でベクトル場の勾配を使用する場合はすぐに、高次のテンソルの縮約が必要になります。

「...（上記で説明したように）この点で設計上の制限がありますが、少なくともサポートされています」と言うとき、機能が不足していること、またはベクトルと転置について基本的なことで対処できないことについて話しているのですか？より高いレベル、または関数を追加することによって？

この提案について、あなたのポイント（A）と（B）を改善することで何か矛盾がありますか？

テンソルの縮約がmatlabsの標準的な乗算演算子*によって、またはその他の組み込みのmatlab関数によってどのようにサポートされているかは実際にはわかりません。 Numpyには機能が組み込まれていますが（名前を忘れました）、覚えている限りではかなり制限されています。

私も常に最も一般的な形式のテンソルの縮約が必要です。そのため、最も一般的なテンソルの縮約を指定することは、効率的に実装することは言うまでもなく、完全に簡単ではないことを私は知っています。 そのため、ユースケースの半分をカバーしていないJuliaベースの標準演算子に、半分機能する機能や特定の機能を詰め込もうとするのではなく、このための特別な関数が必要であると主張しました。 しかし、私は自分の意見を変えてうれしいです。たとえば、他のどの収縮よりもはるかに重要/有用な「標準的な」収縮が1つある場合はどうでしょうか。 ただし、これはドメインに大きく依存する可能性があるため、JuliaBaseで採用するための一般的なルールとしては適切ではありません。

オペアンプ19-okt.-2014 OM 22：52 heeft thomasmcoffee [email protected] HET volgende geschreven：

私の見解では、この問題で以前に対処した2つの主要な課題は次のとおりです。

（A）多次元データを操作するときに、テンソルセマンティクス（収縮の場合）と配列セマンティクス（ブロードキャストの場合）を区別する方法。
（B）より高い次元に一般化する一貫したフレームワーク内に明白で便利な線形代数を埋め込む方法。

この提案がこれらの問題のいずれかをどのように扱っているかは私にはわかりません。 私の知る限り、（A）を達成するには、（現在の機能と同様に）アドホックなユーザー操作が必要です。 怠惰なラッパーを使用して（B）に対処するには、@ timholyによって提案されたSubArray拡張機能のようなものが必要になります。その時点で、それは先ほど説明したマスキングアプローチの怠惰なバージョンになります。 同様のレイジーメカニズム（リストラッパータイプなど）を使用して（A）の追加サポートを提供することを想像できますが、これらすべての場合において、レイジーはオプションの戦略である必要があるように思われます。

「高次テンソルの縮約は、とにかく通常の乗算​​ではサポートされない（そしてサポートされるべきではない）」という@Juthoの見解を共有する人の数はわかりませんが、これ以上異議を唱えることはできません。私は通常のエンジニアリングと見なすものだけを実行します。数学、そして私はいつもそれらを必要としています。 MathematicaやNumPyのような現在の言語にはこの点で設計上の制限がありますが（私が上で議論したように）、少なくともサポートされています！ たとえば、単純な数値解法でベクトル場の勾配を使用する場合はすぐに、高次のテンソルの縮約が必要になります。

—
このメールに直接返信するか、GitHubで表示してください。

これがAの最後のインデックスとBの最初のインデックスの縮約です
数学の点のようなもの

function contract(A,B)
   s=size(A)
   t=size(B)
   reshape(reshape(A, prod(s[1:end-1]), s[end]) *  reshape(B,t[1],prod(t[2:end])) , [s[1:end-1]... t[2:end]...]...)
end

私はいつも、形を変えたり、並べ替えたり、おそらく複雑なもので一般的な収縮を行うことができました
上記のように多かれ少なかれ必要なときに共役

テンソルの大きな問題が実際に何であるかわからない、なぜこれらのいくつかを実装できないのですか？
関数？

はい、正確に。 この号では、前進するために解決したいのは

1. インデックス作成でドロップするディメンションは何ですか？ 「APLスタイル」は議論の余地がないようです。
2. vector'は何を与えますか？

適切なタイプと段階的な関数を使用したテンソルの縮約については、実際にはかなり高性能な実装を取得できると思います。

私の気持ちは、テンソルが自分たちの面倒を見るだろうということです。
その線形代数のユーザーはイライラしません。

私の最大の懸念は

（2D配列から行を取得）*（2D配列）*（2D配列から列を取得）

これは一般的な操作ですが、
（行を取る）covectorまたはおそらくもっと良い
一般的なスロットインデックスでタグ付けします。

@JeffBezanson 、これらの操作がサポートされていると言うとき、組み込みのデータ型と関数は、たとえばMathematicaのDot関数のように、それらを念頭に置いて特別に設計されていることを意味します。 したがって、ユーザーにとって、特定のことを行うための組み込みの、文書化された、および/または明白な方法があります。 どの設計でも、現在の実装と同じように、関数を追加することであらゆるもののサポートを実現できます。 つまり、技術的な競合の問題ではなく、設計の問題です。

@ Jutho 、MATLABをあまり使用しないので、コメントできません。 NumPyの設計は（上で説明したように）Mathematicaの設計よりも一貫性が低いことに同意しますが、より豊富な動作範囲もサポートします。 基本的な線形代数は、それを必要としないユーザーには一般的なテンソル機構を見えなくするべきであることに同意しますが、Juliaの素晴らしい言語機能のため、NumPyとMathematicaの両方が持っているように、それらに異なる実装を導入する必要はないようです。ある程度やらざるを得なかった。 この問題は、少なくとも部分的には、両方に適した統合システムを見つけて、一般的な線形代数の場合にどの特殊化を使用する必要があるかを明らかにすることであるように思われました。たとえば、 vector'についてどうするかなどです。

A [1 、：] * A * A [：、1]＃行列からの行*行列*行列からの列???

正解– A[1,:]' * A * A[:,1]と書く必要があります。

また、v '* wはスカラーですか？

はい、 v'wは同じものです。 この提案の良い点の1つは、安価な構文ハックを完全に排除できることです。

これがそんなにホットなアイデアかどうかわからない...

そうではないと思います。 この提案の目標の1つは、スライスとインデックスのルールを対称にすることです。これにより、インデックスの1つが特別になり、目的全体が無効になるように思われます。 スライスが非対称になる場合は、現在の動作を維持することもできます。

@thomasmcoffeeもっと具体的にする必要があります。 もちろん、誰もが物事が首尾一貫し、文書化され、明白であることなどを望んでいます。問題は、テーブル上の提案がそれらの目標に役立つかどうかです。 たぶん、現在の提案はそれらの目標にまったく影響を与えません。それは問題ありません---それが他の場所での改善につながる限り、私たちはまだ正味の改善があります。

だから私はこれをまっすぐにしましょう

Aが正方形でない場合

| | 現在| 提案| MATLAB |
| --- | --- | --- | --- |
| A * A [1 、：] | いいえ| はい| いいえ|
| A * A [1、：] '| はい| いいえ| はい|
| A [：、1] A | いいえ|
A [：、1] ' A | はい| はい| はい|

Aが正方形の場合

| | 現在| 提案| MATLAB |
| --- | --- | --- | --- |
| A * A [：、1] | はい| はい| はい|
| A * A [：、1] '| いいえ| いいえ| いいえ|
| A [1 、：] A | いいえ|
A [1、：] ' A | いいえ| はい| いいえ|

私はこれに対する答えを投稿したばかりだと誓いますが、どういうわけかそれはエーテルに消えました。 これはすべて正しいです。 現在の配置では、転置するかどうかを決定するときに、行スライスと列スライスのどちらを使用するか、および左または右で乗算するかどうかを考慮する必要があります（列は左に転置され、行は右側に転置）。 提案では、どちらの側で乗算するかのみを考慮します。常に左側で転置し、右側では転置しません。

よろしければ大丈夫でしょうか

dot(x,y)とdot(x.',y)とdot(x,y.')とdot(x.',y.')すべて同じスカラーを与えますか？

すなわちΣᵢconj（xᵢ）*yᵢ

このようにして、あまり考えずにdot（x、A * y）を実行できます。

@alanedelmanによるこれらの例は、APLインデックス付けのために、すべきでない場所で少し後方に転置しているように感じます。 おそらくそれは、私が議論したと思うように、インデックスの次元を保持するバリアントを持つのに十分な動機です（例： A[i; :] ？）

しかし、上記の場合、コベクトルを与える必要があります。

@alanedelman 、 dotこれらのメソッドが存在してはならず、同じ結果が得られる理由はわかりません。

私はいつも、形を変えたり、並べ替えたり、おそらく複雑なもので一般的な収縮を行うことができました
上記のように多かれ少なかれ必要なときに共役

：BLASメソッドを選択した場合、TensorOperations.jlのtensorcontract関数に実装されるのはまさにこの方法です。これは、大きなテンソルにとって確かに最速です。 また、Cartesian.jl関数を使用して（そしてできればステージ関数を使用して）ネイティブのjulia実装を作成しました。これにより、permutedim（追加のメモリ割り当て）が不要になり、テンソルが小さいほど高速になります。

私は、matlabがJuliaにはない組み込み機能を提供しているという誤った主張に応えていました。 ジュリアでは、リシェイプとパーミューテッドの両方が利用可能です。 Numpyには確かにこれを正確に行うテンソルドット関数がありますが、出力テンソルのインデックス順序を指定することはできません。したがって、特定の出力順序を念頭に置いている場合は、後で並べ替えが必要です。

しかし、これは現在のトピックから離れすぎています。これは、ベクトル代数と行列代数の一貫した動作を実際に取得することです。

ステファンの提案は+1。 それは非常に明確ですが十分に柔軟なセマンティクスを与えるようです。 線形代数のユーザーとして、MATLABスタイルの構文に慣れている人でも、ルールは簡単に使用できると思います。

'が一般的に何を意味するのかについて少し混乱しています。 vがベクトルの場合、 v'はtransposeです。 aが2次元配列の場合、 a'もtransposeになります。 これらは両方とも、 bの最初の次元をaの最初の次元と縮小することによって、 b' * aを簡単に形成できるようにするために定義されているようです。

aの次元が> 2の場合、 a'定義についてはコンセンサスが得られていないようです。 次元を逆にする以外の提案を聞いたことがありません。これは、 b' * aがbの最初の次元をaの最初の次元と縮小することと一致します。

動作しているもののサイズを参照せずに、 'が何をするのかを簡潔に述べることができれば素晴らしいと思います。

例えば、より一般的な状況のためのベースで利用可能な別の収縮機能を持つことが合理的と思われるcontract(a, b, 2, 3)の第二の寸法縮小するa第3回でb 。

ところで、 dot(a,b) == a'*bときaとbベクトルですが、 dot(a,b)現在の行列のために定義されていません。 dot(a,b) = trace(a'*b)ますか？

@madeleineudell ：一般的に 'が何を意味するのかについて少し混乱しています。

私はこの懸念を共有します。 基本的に、私の提案では、プロパティ2〜5、7、8、および10を定義特性として使用できます。 つまり、これを保持したい：

• v'は1次元ですが、ベクトルではありません
• v'' === v
• v' == v
• v'wはスカラーです
• v*w'は行列です
• v'*Mはv'と同じ種類のものです
• M'は2次元ですが、マトリックスではなく、マトリックスビューである可能性があります

特に、高次元の配列に対してそれが何を意味するか、または何をするかについての制約はありません。 高次元を含むコベクトルとは何かという一般的な理論があればいいのですが、たとえば、上下の次元を設定したり、各次元にインデックスを付けたりするなど、複雑にしすぎずに実際に実行できるとは思いません。

少なくとも、 'の一般的な規則は、次元を逆にすることではないことは明らかです。これは、ベクトルや共ベクトルに対して行うことではないためです。

ベクトル、コベクトル、および行列の両方について上記の動作をキャプチャする、私が考えることができる唯一の単純なルールは、最初の2つの次元を並べ替えることです（ベクトルには2番目の次元がなく、コベクトルには1番目と2番目の次元がありません）。

2014年10月20日には、午前9時05分で、toivoh [email protected]書きました：

少なくとも、 'の一般的な規則は、次元を逆にすることではないことは明らかです。これは、ベクトルや共ベクトルに対して行うことではないためです。

ベクトル、コベクトル、および行列の両方について上記の動作をキャプチャする、私が考えることができる唯一の単純なルールは、最初の2つの次元を並べ替えることです（ベクトルには2番目の次元がなく、コベクトルには1番目と2番目の次元がありません）。

一般的なテンソルについて考えたいのであれば、これは真実ではないと私は主張します。 行列とベクトルを数値を含むいくつかのブロックとしてのみ考え、vを列として、v 'を行として考える場合は真実かもしれません。

ただし、vをベクトル空間の要素と見なし、w = v 'をvを双対空間V_の要素wにマップする方法と考える場合、wはベクトル、つまり1次元オブジェクトのままです。 一般に、VからV_へのこのマッピングを定義するには、メトリックが必要です。つまり、w_i = g_ {i、j} v ^ jです。 ここで、Vがデカルト空間、つまり標準ユークリッド距離のR ^ nである場合、V *は自然にVと同型です。これは、上位または下位のインデックス（共変または反変）の概念がないため、w_i = v_iであることを意味します。 = v ^ i = w ^ i。 これはほとんどのプログラミングで使用されるケース、つまりJuliaBaseでサポートする必要があるケースであると私は主張します。 （複素ベクトル空間の場合、V *は自然にVbar、つまり共役ベクトル空間と同型であるため、自然マッピングはw_i = conj（v ^ i）です。）

ベクトルを数値のある列として、双対ベクトルを数値のある行として、したがって行列（V \ otimes V_の要素）を数値のあるブロックとして表す規則は非常に便利ですが、高次元も考慮したい場合はすぐに停止します配列、つまり高次テンソル積空間の要素。 その場合、「行ベクトル」、つまり最初の次元のサイズが1である2次元オブジェクトは、matlab / juliaの用語で言うと、テンソル積空間V1 \ otimes V2の要素であり、V1は次のようになります。 R（または他の1次元空間）である。 これがデフォルトの動作として望むものではない可能性があることに同意しますが、matlabのように、一般的な配列の転置を定義してpermutedimを参照しようとしない方がよいと思います。 一般的なテンソルの最初の2次元をデフォルトの規則として逆にすることは、意味がありません。 いくつかの高次テンソル積空間からの要素の転置V1 \ otimes V2 \ otimes…\ otimesVnには一意の定義がありません。 すべての寸法を逆にする規則は、上記のように、ペンローズによる便利なグラフィック表現に由来しています。 さらに、これは行列空間（V \ otimes V_）をそれ自体（V * \ otimes V * = V \ otimes V ）にマップするものです。

私は2つの方法を見ることができます：
1）カルテシアンテンソルの設定内で（つまり、上位インデックスと下位インデックスを区別せずに）、選択した規則を使用して、コンビニエンス演算子 '（および場合によっては*）を任意の高次配列で機能させる。 これは、典型的なユースケースでいくつかの驚くべき結果をもたらす可能性があります。

2） 'と*をベクトルと行列に制限します。 高次配列でエラーが発生しました。 これが最も一般的なアプローチだと思います（Matlabなど）。

この投稿は、昨年私が取った立場とは少し反対側にあるものです。

両側からアンビバレンスを探ります。

それが大丈夫だといいのですが。
ついに、現在のアプローチには論理があることに気づきましたが、それは明確に表現されていませんでした。
それはハックのように見えたので、私を苛立たせました。 どういうわけか私は理解しました
それ、私はそれがもっと好きです。

現在のアプローチでは、すべての配列は無限次元であり、暗黙の1が削除されます。
アポストロフィ演算子 'は、最初の2つの次元を交換することを意味している可能性があります。
しかし実際には、それは今日存在しているので、それは

ndim（A）<= 2？ 交換_first_two_dims：no_op

他のみんながそれを見て、私がそれを見逃した場合は申し訳ありません。 私の心は行き詰まりました
ベクトルは無限次元ではなく一次元であるという考えで、そして
したがって、転置は次元を逆にする必要があり、したがってno_opになります。

これを行うアポストロフィ、または常に交換するアポストロフィで大丈夫です
最初の2つの次元-私は気にしないと思います。 アポストロフィが存在すると思います
多重線形代数ではなく線形代数の場合。

アポストロフィスター（ "'*"）（可能であれば！または不可能な場合は他の何か）かどうかをいじくりまわしました
最後の次元を最初の次元に縮小することを意味する必要があります（Mathematicaのドットのように）
aplインデックスがあり、コベクトルはありません。 私の脳の一部はまだそれを探求する価値があると考えています、
しかし、私が目を覚ますと、これは現在のアプローチがますます良くなっているように見えます。
（今日の後半の気持ちを見てみましょう）

去年このスレッドを始めたことを後悔していませんが、どのような場合かもう一度疑問に思います
今日の人々は本当に迷惑です...例のリストを入手できますか？ ... そして
これらのケースに光を当てることは、私たちが行うことを変えるよりも優れています。

私はこのスレッド全体を読み、多くの多くの原則を見てきました-これは良いことです、
しかし、物事に頭を悩ませるのに十分なユースケースではありません。

私はしばしばイライラしていると言うことができます

[1 2 3] ＃ndims == 2
[1,2,3] ＃ndims == 1
[1; 2; 3] ＃ndims == 1

主に覚えていないようです。

ただの思考実験。 @alanedelmanが'*に対して念頭に置いているのと同様の収縮演算子として機能するように、 *を再定義した場合、どの機能が失われますか？ 線形代数演算での'の必要性を完全に排除しませんか（行列の転置として機能することは別として）？ outer(w,v)簡単に置き換えることができる外積w*v'がないことがわかります。

編集：それがAPLスライスであると仮定します。 たとえば、 A[1,:]*A*A[:,1]は、最初のオペランドを'で転置する必要なしに、期待される結果をもたらします。

私もこれを考えました。 ドット積であるv * wは、ステロイドの過負荷のように見えると思います
エラーが発生しやすい可能性があります。
これは数学の点がそれほど悪くないように見える1つの場所です。

要約すると、最後から最初までの契約は合理的に思えますが、
アポストロフィスターであるか、*であるか、ドットである必要があるかどうか
問題があります。

やや無関係ですが、完全に無関係ではありません...。
もともと誰もがドットスターと読んでいたドットスター（と言われています）は
POINTWISE演算子が何だったので、ポイントスターになることを意味しました
意図されました

私はしばしばイライラしていると言うことができます

[1 2 3] ＃ndims == 2
[1,2,3] ＃ndims == 1
[1; 2; 3] ＃ndims == 1

主に覚えていないようです。

私はいつも「 ,だけを使ってみませんか？」と考えていました。

@alanedelmanが '*に対して念頭に置いているのと同様の収縮演算子として機能するように*を再定義した場合、どの機能が失われますか？

結合性が失われます。たとえば、 (M*v)*vは現在のdot(v,M*v) （スカラー）を与えますが、 M*(v*v)はM.*dot(v,v) （行列）を与えます。

dot収縮演算子（とにかく結合法則ではない）にしないのはなぜですか？ ddot(A::Matrix,B::Matrix) == A⋅⋅B == trace(A'*B)高階収縮を定義することもできます。

それで、ベクトル転置を導入する唯一の目的は、 *非結合性から私たちを救うことであることを正しく理解していますか？ @alanedelmanの例のあいまいさは、ベクトルの1つを転置することで修正できますが（ M*v*v' vs M*v'*v ）、括弧を使用しても同じことができます（ M*(v*v) vs (M*v)*v ）ベクトルの転置を実装する手間を一切かけずに（ @Juthoが高次テンソルの転置を実装することは数学的に意味がないことをすでに指摘しているように）。 私にとっての問題は、どちらの表記法がより読みやすく/簡潔で/エレガントで/純粋であるかということです。

実際、 M*(v*v)と(M*v)*vは現在両方とも次のように解析されます

*(M, v, v)

引数のサイズに基づいて乗算の順序を最適化する行列積を可能にするため、パーサーも変更する必要があります。

しかし、少なくとも個人的には、連想性はかなり大きな問題だと思います。 数学とほとんどのプログラミング言語の間で翻訳する必要があります。 ジュリアにとって、私はまだあなたがあまり翻訳する必要がないことを願っています。

（ @Juthoがすでに指摘しているように、高次テンソルに移調を実装することは、数学的には意味がありません）。

それが私が言ったこととまったく同じではないと思います。

@alanedelmanが '*に対して念頭に置いているのと同様の収縮演算子として機能するように*を再定義した場合、どの機能が失われますか？

結合性が失われます。たとえば、（M_v）_vは現在のdot（v、M_v）（スカラー）を与えますが、M_（v_v）はM._dot（v、v）（行列）を与えます。

ドットを収縮演算子（とにかく結合法則ではない）にしないのはなぜですか？ また、ddot（A :: Matrix、B :: Matrix）==A⋅⋅B== trace（A '* B）のように高次の収縮を定義することもできます。

その推論の行で、ベクトルと行列の乗算演算子はもう必要ありません。ドットですべてを書くことができます。
A∙B
A∙v
v∙A∙w
v∙w

これは@pwlの提案ですが、*はドットに置き換えられています。

しかし、少なくとも個人的には、連想性はかなり大きな問題だと思います。 数学とほとんどのプログラミング言語の間で翻訳する必要があります。 ジュリアにとって、私はまだあなたがあまり翻訳する必要がないことを願っています。

問題の一部は、数学でもさまざまな慣習があることだと思います。 行と列のベクトルの数学の観点から考えていますか、それとも線形演算子と双対空間の観点からより抽象的な動作が必要ですか（演算子はベクトルで乗算されませんが、ベクトルに適用されると思いますので、なぜ書きませんか？ A * vまたはA∙vの代わりにA（v）？

私は便利な構文をあまり必要としません。前者は基本に依存しない数学演算をより明確に表現するため、個人的には毎回v '* wよりもdot（v、w）を書くことを好みます（実際、最初にベクトルから双対ベクトルへの自然なマッピングの前の内積も定義できます）=

あまりにも無知で申し訳ありませんが、なぜM[1, :]転置して、 v'ように振る舞うことができないのですか？

私を悩ませているもののリストに追加します

1.1。

[1 2 3] # ndims == 2
[1,2,3] # ndims == 1
[1;2;3] # ndims == 1

2.2。
v=rand(3)
v' * vは現在ndims == 1持っています（ @StefanKarpinskiの提案はこれを修正します）
(v' * v)/( v' * v )はndims ==2 （これは本当に私を悩ませ、修正されるでしょう）

それでも私は本当にコベクトルを望んでいません
そしてaplインデックスは私が行ったり来たりし続けるものです
---まだ考えていますが、次のようなもののリストを見てみたいです
現在のジュリアの他の人々にバグを報告する

私は間違いなくcdotのアイデアが好きです*演算子に加えて、最後のインデックスを最初のインデックスに縮小する
dot（a、b、..）を許可すると、非常に一般的な矛盾が可能になります。

Numpyの命名規則（そしておそらく私の前の投稿の外観）にもかかわらず、私は一般的なテンソルの縮約にドットを使用することについていくぶん複雑な気持ちを持っています。 これはウィキペディアの最初の文です：

数学では、内積、または内積（またはユークリッド空間のコンテキストでは内積）は、2つの等しい長さの数のシーケンス（通常は座標ベクトル）を取り、1つの数を返す代数演算です。

私の考えでも、ドットはスカラーを返す必要があります。

@ brk00 、あなたの質問の問題は、これを高次元/高ランク（私はこれの世界次元が本当に嫌いです）配列のスライスに拡張する方法が明確でないことです。

あまりにも無知で申し訳ありませんが、なぜM [1 、：]を転置して、v 'のように振る舞うことができないのですか？

それは可能ですが、これをどのように一般化しますか？

@Jutho 、申し訳ありませんが、

@alanedelman ：

私を悩ませているもののリストに追加します

[1 2 3] ＃ndims == 2
[1,2,3] ＃ndims == 1
[1; 2; 3] ＃ndims == 1

連結動作はこの問題とは無関係です。 これ以上水を濁さないようにしましょう。

*演算子に加えて最後のインデックスを最初のインデックスに縮小する `cdotのアイデアが間違いなく好きです
dot（a、b、..）を許可すると、非常に一般的な矛盾が可能になります。

これも接線です。 配列とスライスに集中しましょう。

現在のアプローチでは、すべての配列は無限次元であり、暗黙の1が削除されます。

これは実際には真実ではありません。 これが当てはまる場合、 ones(n) 、 ones(n,1) 、 ones(n,1,1)などの区別はありません。しかし、これらはすべて異なるタイプの異なるオブジェクトであり、それぞれに等しくはありません。その他。 _同様に_動作するように実装するように努力していますが、実際に無限次元である配列とはかけ離れています。

現在厄介なもののリストは、上記の提案の優れた特性（のサブセット）を大部分反映しています。 すなわち：

1. 非対称スライス動作–トレーリング寸法は特別です。
2. v'' !== v –実際にはv'' != v ; これは、ランクが同じではないためです。
3. v' != v –同じ取引。
4. v'wは1要素のベクトルであり、スカラーではありません。
5. A*_mul_B*特別な解析が必要です。これは、これまでで最もひどいことです。

v' == vビットを除いて、 @ StefanKarpinskiのほとんどのポイントに同意します。これらが等しくなければならないと思います。 はい、それらは同型である可能性がありますが、動作が非常に異なるという点で、依然として異なるオブジェクトです。行列MとM'も同型ですが、これらを等しくしたいとは思わない（もちろんエルミートでない限り）。

Covectorタイプに関する私の一般的な見解は、それらは比較的軽量であるというものでした。基本的な操作（乗算、加算など）を除いて、あまりにも多くの操作を定義することは避けます（インデックスを定義することさえ躊躇します）。 ）。 それを使って何かをしたい場合は、それをベクトルに変換して、そこで作業を行う必要があります。

さん@StefanKarpinskiの彼の一般的な承認を含むテイク、の見解を@simonbyrneする1。

@simonbyrneにも同意します。

はい、 vとv'は異なるタイプですが、同じ形状とデータを持つ異なる配列タイプは同じであるとすでに考えています（たとえば、 speye(5) == eye(5) 。 コベクトルがスパースと異なるのはなぜですか？

コベクトルが行行列のようにブロードキャストされることを願っています。 等しいと見なされる配列AとB場合、これまでのところ、

all(A .== B)

1つがベクトルで、もう1つが共ベクトルの場合、これは当てはまりません。

私にとって、コベクトルは、ベクトルや列の行列というよりも、行の行列に似ています。

重要な質問はsize(v'とは何ですか？ 答えが(length(v),)場合、 v == v'は正しいはずだと思います。 size(v') == (1,length(v))場合、おそらくfalseであるはずですが、おそらくv' == reshape(v,1,length(v))はtrueであるはずです。 したがって、問題は、 v'特別な種類のベクトルにするか、特別な種類の行列にするかということです。

この問題は、転置が実際に何を意味するのかということであると私はますます確信しています。

コベクトルは実際には配列ではないので、それらがどのような「形状」を持っているかを実際に言うことはできないと思います。 コベクトルは実際にはそれが何をするかによって定義されます。つまり、 *(::Covector, ::Vector)はスカラーを与えます。 AbstractVectorはそれを行わないので、実際には同じことではありません。

もう1つの問題は、複雑なフィールドにあります。 v' == vまたはv.' == vますか？

@simonbyrne ：

コベクトルは実際にはそれが何をするかによって定義されます。つまり、 *(::Covector, ::Vector)はスカラーを与えます。 AbstractVectorはそれを行わないので、実際には同じことではありません。

これは本当に良い点です。 ただし、 v'をオブジェクトとして使用できない場合は、かなりイライラする可能性があります。 おそらく正しいアプローチは、 v'を面白いベクトルではなく面白い行行列として扱うことです。

おそらく正しいアプローチは、v 'を面白いベクトルではなく面白い行行列として扱うことです。

一種ですが、 AbstractMatrixサブタイプでもないと思います。 AbstractCovectorはトップレベルのタイプである必要があると思います。 length(::Covector)を定義できれば幸いですが、 sizeメソッドを定義する必要はないと思います。

放送の扱いについてはよくわかりません。合理的な基準を考え出せない限り、放送方法を定義しないことに誤りがあります。

この議論は、エンジニアリングで使用されるような転置とベクトルの使用に向かって収束しているようです。つまり、すべてを行列と見なします。 ベクトルを列、対流式放熱器を行と考えてください。 これはデカルト空間（典​​型的な使用例）のベクトルと線形写像には適していますが、多重線形代数やより一般的なベクトル空間などに一般化しようとすると失敗し始めます。デカルト空間多くのものは同等ですが、一般的な空間とは同等ではありません。 ジュリアのデフォルトの振る舞いとして、私は必ずしもこれに反対しているわけではありませんが、「数学的に正しい」かのように、上記のステートメントのいくつかに本当に同意しません。 だから私は以下のものと矛盾させてください。

2014年10月20日には、17時39分で、サイモン・バーンズの[email protected]は書きました：

v '== vビットを除いて、 @ StefanKarpinskiのほとんどの点に同意します。これらが等しくなければならないと思います。 はい、それらは同型である可能性がありますが、動作が非常に異なるという点で、依然として異なるオブジェクトです。行列MとM 'も同型ですが、（もちろんエルミートでない限り）等しくなることはないと思います。

このステートメントは、どのレベルでも意味がありません。

1）、あなたはここで同型の意味を乱用していると思います。 同型は、2つのスペース間の関係です（この設定では）。 一般に、すべての（実）ベクトル空間Vには、線形関数の双対空間V *があります（複雑な空間の場合、共役空間と共役空間の双対もあります）。 これらは通常、異なる空間であり、一方から他方への一意のまたは自然なマッピングすらありません。つまり、一般に、Vの要素vをV *の要素phiに関連付ける意味はありません。 唯一の一般的な操作は線形関数を適用することです。つまり、phi（v）はスカラーです。

VからV *への自然なマッピングは、双線形形式V x V->スカラー（通常は内積/距離）ができたら定義できます。 次に、phi_i = g_ {i、j} v ^ jを定義できます。

2）実際、「ベクトルの転置」に関連する自然な操作はありません（ポイント3を参照）。 この混乱は、列行列を使用してベクトルを識別することから生じます。
おそらく強すぎると思いますが、実際には、ドットや外積/テンソル積の操作では取得できないベクトルの転置のユースケースを見たいですか？

ただし、ベクトルを双対ベクトルにマッピングする方法として転置を使用する場合、つまりVのvをV_のあるphi = v 'にマッピングする場合は、標準のユークリッド内積（g_ { i、j} = delta_ {i、j}）。 その時点で、共変指数と反変指数の区別をなくし、本質的にカルテシアンテンソルを操作し、VとV_は自然に同型になります。 上で述べたように、w_i = v ^ i = v_i = w ^ iなので、そうです、v == wであり、これら2つを区別するものは何もないとさえ言えます。

3）「転置」操作は、元々V-> W（http://en.wikipedia.org/wiki/Dual_space#Transpose_of_a_linear_map）の線形写像に対してのみ定義されており、実際、それでもあなたの考えを意味しない場合があります。 線形写像Aの転置：V-> WはW _-> V_からの写像A ^ Tです。つまり、W_のベクトル、双対ベクトルに作用し、V_の要素、つまりVの共ベクトルを生成します。行列Aの通常の転置A ^ Tの観点から考えると、この行列A ^ Tは、W *のベクトルを表す列と乗算され、これから出てくる列はVの共ベクトルを表します。したがって、この時点で、行ベクトルを使用した双対ベクトルの識別はすでに失敗しています。

ただし、V *とW *が標準のユークリッド内積を介してVとWで識別される実数ベクトル空間の一般的な使用例では、線形マップの転置は、その線形マップの隣接で識別できます。ほとんどの人が考えるように、V-> Wからのマップは、マップの転置にも当てはまります。 複雑なケースでは、通常の行列転置（複素共役なし）はマップW _-> V_としてのみ意味があり、マップW-> Vとしては基本に依存しない定義ではないため、操作上意味がないため、これは失敗します。

高次元の配列で転置が何を意味するかについては、私たちが収束しているmatlab / Engineeringのアプローチの範囲内で、エラーである必要があり、一般化されていません。 これは、それを定義する方法がないという意味ではありません。 問題は、高次配列が何を表すかということです。 それはテンソル積空間V1 \ otimes V2 \ otimes…\ otimes VNの要素ですか、それはV1 x V2x…xVNに作用する多重線形写像ですか、それはいくつかのテンソル積空間V1 \ otimes V2 \ otimesからの線形写像ですか…\ otimesVNから別のテンソル積空間W1 \ otimes W2 \ otimes…\ otimes WM？ 2次元の場合、解像度があります。 線形写像の識別A：V-> WとW \ otimes V_のベクトル、線形写像の意味での転置は、このテンソル積空間の空間の反転に対応します。A^ i_j-> A_j ^ iとA ^ TのV_ \ otimes W = V * \ otimes W _、これは確かにW

結論として、問題は、ジュリアのベクトルが数学的な意味で任意の一般的なベクトルのプロパティをキャプチャする必要があるかどうか、またはそれが数字の列、リスト、…を表すだけかどうかだと思います。ベクトル、テンソル、…という言葉はうまくいきます-数学で定義された操作および基礎に依存しない意味。これは、JuliaVectorで定義する操作の種類と競合する可能性があります。 逆に、一部のオブジェクトは実際には数学的な観点からのベクトル（双対ベクトルなど）であり、標準のJulia（Abstract）Vectorタイプには異なるベクトル空間を区別する方法がないため、JuliaVectorsで識別すべきではありません。

その点で、行列という用語は過負荷がはるかに少ないため、数学的な観点からも、行列は特定の基準で線形マップの便利な表現にすぎないため、ある程度の非対称性があります。 線形写像を行列としてではなく関数として表現したい場合も多いことに注意してください（この問題は、eigなどの引数で以前に発生しました）。 その点で、matlabが真に1次元の構造であるベクトルを持っていなかった理由がわかります。 このアプローチでは、とにかく、すべてが「マトリックス」、つまり数字のあるブロックとして解釈されます。

質問？ cを共ベクトルとします。 fft（c）とは何ですか？

回答：予想外の可能性のある方法で複素共役を取るfft（c '）'
fft（c）と比較した場合

ユーザーはそれが未定義であるという恩恵を受けるかもしれません
（または、十分に文書化されていれば、おそらくこれはユーザーにとって良いでしょう??）

私はこれらの種類のものがもっとたくさんあるに違いない

今のところBaseで行うべき正しいことは、以下を定義することだけだと思います。

• コベクトルに別のベクトルを掛ける
• コベクトルと行列の積
• ベクトルを取得するためのcovector '

今のところ、コベクトルの最小サポートに+1します。

はい、+ 1。

だから私が言ったなら私はそれをかなり確信しています
norm（covector、q）はnorm（vector、p）である必要があります。ここで、1 / p + 1 / q = 1
ホルダーの不等式から、それは長い間実装されないでしょう。 :-)

p = q = 2を天に感謝します

実装するのはそれほど難しいことではありません。

norm(c::Covector, q::Integer) = norm(c.vector, q/(1-q))

q == 0とq == 1を回避するために、追加のチェックが必要になる可能性があります。

q == 1で大丈夫だと思います

Med venlig hilsen

アンドレアスノアック

2014年10月22日午前15時19分GMT-04：00ステファンKarpinski [email protected] ：

実装するのはそれほど難しいことではありません。

norm（c :: Covector、q :: Integer）= norm（c.vector、q /（1-q））

q == 0およびq == 1を回避するために、追加のチェックが必要になる場合があります。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-60139762 。

私はcovector提案（私が主にサポートしている）の記述に取り組んでいますが、 @ StefanKarpinskiの「面白い行行列」の概念を正確にする1つのポイントを投稿すると便利かもしれません。

コベクトルはベクトルではありませんが、その理由の説明は必ずしも明確ではありません。 コベクトル（または物理学者が呼ぶようにブラベクトル）は、ベクトルを食べて内積である数を吐き出す線形汎関数です。

より正確に：

• V = V(F)とW = W(F) 、要素のいくつかのフィールドF上のベクトルとします。
• vとwは、それぞれVとW要素であるベクトルです。
• <.,.>は、 <.,.> : V × W → Fやv, w ↦ <v, w>などの内積になります

v対応する共ベクトルは、マッピングw ↦ <v, w>を実行する線形汎関数v' : W → Fです。

通常の説明は、 v'が双対空間V*要素であり、双対空間が何であるかについては他にあまり言及されていないということで終わります。

コンピュータサイエンスの人々のために、最初のパラメータに関する内積のカリー化としてのv'と、1つのパラメータである関数のコレクションとしてのV*簡単な説明があります。異なる最初のベクトルを持つカリー。

このウィキペディアの記事は、2つの説明に関連するさまざまな表記法を調整するのに役立つ場合がありますが、まったく同じ概念を表現しています。

また、私は当初、コベクトルへのインデックス付けは禁止されるべきだと考えていました。 ただし、 v'[1]インデックス付けは、正規基底ベクトルe₁ = (1, 0, ...)にv'を適用することと同じであるため、 v'[1]は<v, e₁>として定義できます。 1:nようなより一般的なインデックス付けのセマンティクスは、 v'を適切な射影行列に適用することから自然に続きます。各列は標準基底ベクトルです。

＃987のコンテキストでコベクトルのインデックス付けセマンティクスを検討すると、コベクトルがAbstractVectorない別の理由が得られます。一般に、 v'安価にインデックス付けすることはできません。 <v, e₁>ように計算します。 一般に、行列<v, w> = v'*A*wに関して内積を定義することができ、インデックス作成のコストは、内積A*w （またはA'*v ）によって支配されます。これは確かにです。 AbstractVectorとしての資格を得るには高すぎる。

DFTと規範について話しているので...これは今日私の頭に浮かんだ

場合はfベクトルの関数であり、スカラーを生成し、その後、私は希望diff(f)受け入れる関数とVectorし、生産Covectorそのため、 f(x) ~= f(x0) + diff(f)(x0) * (x-x0) 。 勾配の非常に一般的な使用法は、入力の増分変化が与えられた場合に、関数の出力の増分変化の線形近似を取得することです。 入力がベクトルの場合、勾配が入力のすべての次元に沿って収縮するものであるのは自然なことです。

しかし、最急降下法を実装する場合は、 xの勾配（のスケーリングバージョン）をそれ自体に追加する必要があります。 この意味で、勾配は最も急な方向を指すベクトルであり、そのノルムはその最も急な方向に沿った変化率に比例します。

私の腸は、「ある点でのベクトル入力関数の勾配は共ベクトルである」と言っています。

今のところBaseで行うべき正しいことは、以下を定義することだけだと思います。

コベクトルに別のベクトルを掛ける
コベクトルと行列の積
ベクトルを取得するためのcovector '

私の以前の恐ろしい投稿からあなたが得たかもしれない印象にもかかわらず、これに+1。

それにもかかわらず、これに関するいくつかの意見：

私はcovector提案（私が主にサポートしている）の記述に取り組んでいますが、 @ StefanKarpinskiの「面白い行行列」の概念を正確にする1つのポイントを投稿すると便利かもしれません。

コベクトルはベクトルではありませんが、その理由の説明は必ずしも明確ではありません。 コベクトル（または物理学者が呼ぶようにブラベクトル）は、ベクトルを食べて内積である数を吐き出す線形汎関数です。

双対ベクトル/共ベクトル（線形汎関数という用語も好む）は、内積がなくても定義できると思います。 VからV *へのマッピングを定義する場合は、内積が必要なだけです。

より正確に：

V = V（F）およびW = W（F）を要素Fのいくつかのフィールド上のベクトルとします。
vとwは、それぞれVとWの要素であるベクトルです。
<。、。>は、<。、。>：V×W→Fおよびv、w↦のような内積である
2つの異なるベクトル空間VとWの間に内積を定義することはかなり奇妙であり、不可能だと思います。正定性の特性をどのように定義しますか？
vに対応する共ベクトルは、マッピングw↦を実行する線形汎関数v '：W→Fです。。

通常の説明は、v 'が双対空間V *の要素であり、双対空間が何であるかについては他にあまり言及されていないということで終わります。

確かに有限次元の場合、双対空間はその名のとおりベクトル空間であることはかなり明らかだと思います。 しかし、私の以前の暴言の要約は、ジュリアの（抽象）ベクトルタイプはリストに似ているということです。 特定のベクトル、およびベクトルの数学的構造を持たない他の1次元データ構造を表すために使用できますが、数学的ベクトルであるすべてのオブジェクトをキャプチャすることは十分に一般的ではありません（異なるベクトルを区別できないため）スペース）。

＃987のコンテキストでコベクトルのインデックス付けのセマンティクスを検討すると、コベクトルがAbstractVectorsではないもう1つの理由が得られます。= v'_A_wであり、インデックス作成のコストは、matvec製品A_w（またはA'_v）によって支配されます。これは、AbstractVectorとしての資格を得るには確かに高すぎます。

これは一種のループ引数です。 上記のように、線形汎関数（covector）はより一般的であり、内積のないベクトル空間に対しても存在します。 第2に、メトリックが正定値行列Aの場合、ベクトルvからコベクトルへの自然なマッピングは実際にv'_Aです。 しかし、ここでこのv 'は何ですか？ それはすでにvから標準のユークリッドノルム（メトリックとしてのアイデンティティを持つ）に関して定義された別のコベクトルへのマッピングですか？ いいえそうではありません。 ベクトルに反変（上位）インデックスがあり、共ベクトルに共変（下位）インデックスがある場合、メトリックAには2つの下位インデックスがあり、内積は次のようになります。= v ^ i A_ {i、j} v ^ j。 したがって、このマッピングは、（phiを使用してベクトルvに関連付けられたコベクトルを使用して）phi_j = v ^ i A_ {i、j}と書くことができます。 （これは、w ^ i = O ^ i_j v ^ jの形式である一般的な線形演算子とは異なることに注意してください）。 したがって、この式v'_Aのvは、依然として上位インデックスを持つものであり、同じベクトルのままです。

したがって、実際、私が上記で述べようとしていた点の1つは、実際にコベクトルを操作しようとしていないときに、人々がv 'を書くことが多いということです。 内積などのベクトルで定義された式を書き込もうとするだけです。または、v'_A_wとしておなじみの行列表現内のv ^ i A_ {i、j} w ^ jのようなもの。 標準のユークリッド内積v'wでさえ、v ^ i delta_ {i、j} w ^ jとして読み取る必要があり、対流式放熱器を導入する必要はありません。 上記のように、スカラー積の隠された形式ではない実際の適切なコベクトルの使用は、ほとんどのアプリケーションでかなり制限されていると思います。 人々は便利な行列構文を使用できるようにv 'を書くだけですが、実際に行っているのは、コベクトルではなくベクトルに関して定義された内積などを計算することです。

余談ですが、ステファンの最初の提案のようにv '== vである場合、乗算の結合性について以前にいくつかの意見がありました。 ただし、これがなくても、v 'が通常のベクトルで識別されない共ベクトルであっても、*が結合法則であるとは言えません。
A_（v'_w）は行列です
（A_v '）_ wはエラーを生成しています

スカラー値関数の勾配は、実際にコベクトルの適切なアプリケーションの1つです。つまり、引数がない場合、勾配はコベクトルです。 共役勾配法のようなアプリケーションで暗黙的に想定されているのは、これらの共ベクトルをベクトルにマッピングするためのメトリック（実際には逆メトリック）があるということです。 それ以外の場合は、x ^ i（位置ベクトル）+ alpha g_i（勾配）のようなことをしても意味がありません。 これを記述する適切な方法は、x ^ i + alpha delta ^ {i、j} g_jです。ここで、delta ^ {i、j}は逆メトリックです。 自明でないメトリックを使用して多様体で最適化手法を定義しようとする場合、この（逆）メトリックを考慮する必要があります。 これに関する素晴らしい本があります：
http://sites.uclouvain.be/absil/amsbook/
および対応するmatlabパッケージ：
http://www.manopt.org

2014年10月22日で、夜10時52時、goretkin [email protected]書きました：

DFTと規範について話しているので...これは今日私の頭に浮かんだ

fisがベクトルの関数であり、スカラーを生成する場合、diff（f）を、ベクトルを受け入れてCovectorを生成する関数にして、f（x）〜= f（x0）+ diff（f）（ x0）*（x-x0）。 勾配の非常に一般的な使用法は、入力の増分変化が与えられた場合に、関数の出力の増分変化の線形近似を取得することです。 入力がベクトルの場合、勾配が共ベクトルであるのは自然なことです。

しかし、最急降下法を実装する場合は、xの勾配（のスケーリングバージョン）をそれ自体に追加する必要があります。 この意味で、勾配は最も急な方向を指すベクトルであり、そのノルムはその最も急な方向に沿った変化率に比例します。

私の腸は、勾配は共ベクトルであることがより重要であると言います。

—
このメールに直接返信するか、GitHubで表示してください。

A_（v'_w）は行列です
（A_v '）_ wはエラーを生成しています

やばい。

このスレッドは、ユーモラスな画像が含まれている投稿のために延期されました。

@Jutho私は最も一般的な形式の双対空間を使用していないことを認めますが、バナッハ空間のフレームワークを使用して双対空間を定義するという選択を考えると、私の説明がどのように循環しているかはわかりません。 とにかく、バナッハ空間形式は、有限次元のベクトル空間にとってはすでにやり過ぎです。

サーキュラーは確かに正しい用語ではありません。 その段落で私が言おうとしていたのは、エントリの効率的な評価に関するこの推論の線を逆にすることができるということです。たとえば、湾曲した多様体の（共役）勾配の場合、勾配（コベクトル） g_iを推測するからです

1. 双対空間は確かにベクトル空間であるため、その要素はベクトルです。 ただし、目的は、ベクトルの数学的意味を持つすべてのオブジェクトがJuliaのAbstractVectorサブタイプになることや、 AbstractVectorサブタイプであるすべてのオブジェクトが適切な数学的特性を持つことではありません。ベクトルの。 その意味で、私はMatrixという名前よりもVectorという名前の方がはるかに好きです。 したがって、この提案の一部として導入されているCovectorタイプが何であれ、 AbstractVectorまたはAbstractArrayサブタイプであってはならないという事実に同意できると思います。 、V *がVと自然に同型である場合でも（おそらくアプリケーションの半分を占めるデカルト空間）。
2. 内積を使用すると、VからV_へのマッピングを作成できますが、V_が存在するための前提条件ではありません。 確かに、これは無関係な問題のように聞こえます。プログラミングでは常に有限次元のベクトル空間があり、常に内積が存在するためです（アプリケーションに関連するものではない場合もあります）が、私が試みた実用的なポイントmakeはこれです。 @goretkinによる素敵な勾配の例のように、プログラミングにはv'書くほとんどのアプリケーションでは、実際にはコベクトルを構築しようとはせず、双線形を書き込もうとしています。 v'_A_w = v ^ i A_ {i、j} w ^ jまたはv'w = v ^ i delta_ {i、j} w ^ jのように、2つのベクトル間のマッピング（つまり、V x Vからスカラーへ）便利な行列表現。 私はdot(v,A*w)明示的に書くことを好みますが、それは個人的な選択です。 行列の上位または下位のインデックスに関する情報がないため、 v'*A*wようなスカラー式で、 v'とw両方がベクトルまたは共ベクトルのいずれかになるユースケースを構築できます。数学的な意味で。 これの唯一の結果は、 Vectorという名前と同じように、数学が多すぎるため、 v' Covectorのタイプを呼び出すことに本当に満足しているかどうかわからないことです。ほとんどのアプリケーションで正当化されない可能性のある含意。これにより、このように、より多くの（ほとんど無関係な）議論につながります。

勾配が共ベクトルである場合の
私は最初にスティーブ・スミスの博士論文からこれを学び、このアイデアを使用しました
固有値計算のための共役勾配のこの漠然とした考えを明確に説明するために
人々が化学や物理学で話していたものです。

私は内部的にどれほど一貫しているかについてますます驚かされてきました
自己完結型は、1つの上位インデックスと1つの下位インデックスを持つランク2テンソルの世界です。
これは、従来、行列計算または単なる古い線形代数と呼ばれているものです。
ちなみに、norm（v、p）やfft（v）のような関数の例はたくさんあります。
それらがベクトルか共ベクトルかは異なりますが、良い例は1つもありません（まだ！）
ベクトルと1列の行列で自然に異なる関数の。
（誰かが私を助けてくれます、確かに1つ、さらにはたくさんあるに違いありません!!）

私も数年前から@juthoのようにその抽象的なベクトルを心配してきました
スペースはまだジュリアへの道を見つけていませんでした、私は@StefanKarpinskiとチャットしたことを覚えています
数年前の私のホワイトボードでこれについて。 それでも、の包括的な懸念
1）Juliaの新規参入者は、簡単な経験と
2）パフォーマンス
この派手なものを打ち負かす必要があります。

@jiahaoと話をした結果、2つの非常に特別な世界があることに本当に
線形代数（1つのcontraと1つのcoを持つ配列）と単純なテンソルがあります
（誰もが共同であり、反対はありません）。 後者はAPLaMathematicaでうまく機能します。
前者は線形代数全体であり、以前はMATLABで最もよくキャプチャされていました。
それらは2より大きい次元の配列に接ぎ木されました。より完全な一般性があります
@JeffBezansonとの言葉の後、それはそれほどクレイジーではなかったように見えました。

ちなみに1年くらいかかると思いますが、ようやく真剣に受け止めています:-)

について
A_（v'_w）は行列です
（A_v '）_ wはエラーを生成しています

行列乗算 "*"のみが結合法則です。 オーバーロードされたスカラー時間行列は決してありませんでした
連想。 数学でも、MATLABでもありません。

A_（v'_w）は行列です
（A_v '）_ wはエラーを生成しています

良いキャッチ。 エラーがない場合に異なる答えが得られる場合はありますか？ 関連する質問：スカラー*コベクトルは何をすべきですか？

オーバーロードされたスカラー時間行列は、結合的ではありませんでした。 数学でも、MATLABでもありません。

行列とスカラーのみを含む演算は結合法則

スカラー行列の追加は、分配性を台無しにするため、より大きな懸念事項です（ただし、正しく思い出せば、議論はそれを維持するために解決されたと思います）：

(A+s)*v != A*v + s*v

これは非常に素晴らしい要約です：

@jiahaoと話をした結果、2つの非常に特別な世界があることに本当に
線形代数（1つのcontraと1つのcoを持つ配列）と単純なテンソルがあります
（誰もが共同であり、反対はありません）。

この議論がより一般的なケースをサポートすることではないことは明らかです。それは完全な一般性を必要とせず、現在のAbstractArray階層に含めることができず、パッケージ（私が実際に作業している）により適している人々にとっては混乱しすぎます。オン）。 しかし、これら2つの特別な世界は相互に互換性がないため、どちらをサポートしたいのかという議論は確かです。

前者では、すべてのベクトルvは列であり、すべてのv'は共ベクトルであり、すべての行列は線形演算子V-> Wです（たとえば、W⊗V_に存在します）。これは、たとえば双線形の表現を除外します。 V x V->スカラー（例：v ^ i A_ {i、j} w ^ j）をマップします。これには、2つの低いインデックスを持つ行列が必要です（例：V_⊗W_に存在する）。 もちろん、実際に使用してv'_A*wと書くこともできますが、選択したオブジェクトの命名法と矛盾します。 さらに、高次配列がどの空間に存在するかを指定しません。

後者の場合は（V == V *）であるため、この問題は解決されますが、 v' == v驚くべき結果が得られます。 さらに、この解は実際には実際のベクトル空間に限定されます。これは、標準のユークリッド内部積を持つ複雑な空間（つまり「複素カルテシアン空間」）でも、双対空間は自然にVと同形ではなく、conj（V）（V bar）、共役ベクトル空間（http://en.wikipedia.org/wiki/Complex_conjugate_vector_spaceのヒルベルト空間を参照）

非結合性に関しては、その点で、 v'*vがスカラーではなく配列を生成する現在の動作は、実際にはより一貫性があります。それ以降、 A*(v'*v)と(A*v')*v両方が生成されます。

物事の「線形代数」側は、ベクトルと共ベクトルを表現する方法のさまざまな選択肢にさらに解決できます。

• Covector、別名「面白い行ベクトル」の提案は、最近議論しました。
• Matlabなどによって承認された、（N-vectors as Nx1-matrices）、（N-row-vectors as 1xN-matrices）を圧縮する「真のベクトルなし」のセマンティクス。
• 現在のジュリアの方法-密なNベクトルとNx1行列を混同せず、疎なNベクトルとNx1行列を混同し、N行ベクトルを1xN行列として表します。

「真のベクトルがない」世界では、（スカラー、1-ベクトル、および1x1-行列）も厳密に統合する必要があるのではないかと思います。 @alanedelmanと私は昨日これについて話し合っていました。数値線形代数では、ベクトル*スカラーとスカラー*ベクトルの可換性がどこでも使用されていますが、ベクトル*スカラー積は（N、）*（を実行しているかどうかを気にしないものです。 、）または（N、1）*（1,1）。

1）結局のところ、最も重要なことはA）使いやすさとB）パフォーマンスです。
2）2つの世界は完全に調和して共存できる必要があります。 エンジニアリング作業を行うとき、私の意見では、テンソル表記ほど直感的で簡単なものはありません。 可能であれば、環境フラグを有効にするか、プログラムの開始時にパッケージをインポートすることをお勧めします。 これにより、使いやすさと簡単なプログラミングロジックが可能になります。 これは不可能ですか、それとも包括的なスキーマを1つ選択する必要がありますか？

2つの選択肢があるようです
1）ツールボックス、パッチ、または環境フラグのインポートを有効にして、同時に機能させる
2）特別な世界を統一することができ、それでも使いやすく高速な言語を構築する

これがどれほど有望かはわかりませんが、興味深い可能性のある研究分野に出くわしました。

私はあなたの注意を以下に向けることができます：

幾何代​​数研究グループ
http://www.mrao.cam.ac.uk/~clifford/pages/introduction.htm

幾何代​​数の講義コース
http://www.mrao.cam.ac.uk/~clifford/ptIIIcourse/course99/

幾何代​​数の物理的応用
http://www.mrao.cam.ac.uk/~clifford/ptIIIcourse/

21世紀の物理学と工学のための統一された数学言語
http://www.mrao.cam.ac.uk/%7Eclifford/publications/ps/dll_millen.pdf

幾何代​​数
http://arxiv.org/pdf/1205.5935v1.pdf

幾何代​​数コンピューティングの基礎
http://link.springer.com/book/10.1007%2F978-3-642-31794-1

幾何代​​数コンピューティング
http://link.springer.com/book/10.1007%2F978-1-84996-108-0

これをもう少し調べてみると、本当にすごいようです。

代数と幾何学が分離されている限り、それらの進歩は遅く、それらの使用は制限されています。 しかし、これら2つの科学が統合されたとき、それらはそれぞれの相互の力を貸し出し、完全に向かって一緒に行進しました。

• ジョセフ・ルイ・ラグランジュ

眼鏡が必要で、眼鏡が必要だとは知らないことを想像してみてください。 そして、メガネを手に入れると、思いがけず世界が変わります。 GAはあなたの脳の内側のための眼鏡のようなものです。

• パブロ・コラピント

この男は正しい考えを持っているようです... https：//github.com/wolftype/versor

典型的な行列演算ライブラリには、ベクトルと行列の乗算用にテンプレート化されたインライン関数があります。 幾何代​​数は、他の多くの数学（行列、テンソル、ベクトル、およびリー代数）を組み合わせたものです。 ベルソルも同様ですが、ステロイドでは、さまざまなサイズのベクトルとスパース行列はすべて単にマルチベクトルと呼ばれ、xyz方向と変換行列だけでなく幾何学的要素を表します。 円、線、球、平面、点はすべて代数的な要素であり、これらの変数を回転、ねじり、拡張、および曲げる演算子も同様です。 これらの要素と演算子はどちらも、多くの多くの異なる方法で一緒に乗算されるマルチベクトルです。

このビデオでは、プログラムされたGA数学言語であるVersorについて詳しく説明します。
https://www.youtube.com/watch?v=W4p-e-g37tg

これらはこのためのスライドです。 https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/generic_spaces.pdf

コンパイル時の速度が最適化された、驚くべきテンソル計算を非常に簡単に行うことができます。

@ esd100 、このスレッドでの議論をタイトルの特定の問題に焦点を合わせて続けることが役立つと思います。

@johnmyleswhite 「テンソル」という用語を検索したところ、171回（現在は172回）言及されていました。 私はあなたの声明に同意しますが、一般的に、このスレッドには157のコメント（現在は158）があり、そのうちのいくつかは元の投稿のタイトルを直接的および間接的に扱っています（ベクトルを真剣に転置します）。 私の投稿は、幾何代数を介してテンソル数学の新しいアプリケーションで何ができるかについての視点を増やすことによって、元の投稿のタイトルを間接的に扱っていると思います。 私の意見では、ベルソルが持つような高次元の力をジュリアに組み込むことは、ジュリアの追加の有益な機能になるでしょう。 youTubeビデオのタイトルは、「ジェネリックスペースのジェネリックプログラミング：C ++ 11を使用したコンパイル時の幾何代数」でした。 それがC ++ではなくJuliaになれない理由がわかりません。 繰り返しになりますが、私は数学者でもコンピューター科学者でもありません。

@ esd100幾何代​​数は興味深いものですが、この問題がカバーする最も一般的なものではありません。 私たちが主に関心を持つ幾何代数は、実際のクリフォード代数Cl（R ^ n、I）です。 ただし、複素数ベクトルCl（C ^ n、I）のようなクリフォード代数や、任意のフィールドや非可換環Cl（F ^ n、I）のような代数など、幾何代数ではない他のクリフォード代数にも関心があります。 。 さらに、必ずしもクリフォード代数に限定する必要はありませんが、線形代数が、二次形式（内積）が必ずしも定義されていない、より一般的なテンソル代数設定にどのように一般化されるかを検討したいと思います。

テンソル代数の設定では、OPの「 v'はノーオペレーションです」という提案は、逆転準同型に一貫して一般化されるためかなっています。 ただし、これはテーブルにある少なくとも3つの提案のうちの1つにすぎません。 「v」が共ベクトルを生成するテンソル余代数につながる双代数拡張を検討することもできます。 しかし、「真のベクトルなし」の提案がどのようにテンソル代数に一般化されるかはわかりません。

@jiahao非常に有益な回答をありがとうございます。 主題をある程度熟知している人に光を当ててもらうのはいいことです。 理解を深めるために、これらのトピックをさらに詳しく調べたいと思います。 BLASの超最適化コードが存在する理由に興味がありますが、クリフォード代数のようなより複雑な代数の超最適化コードは存在しません。

この議論がまだ続いているかどうかはわかりませんが、これらの問題はジュリアを使用する私の最も重要な（そして迷惑な）部分のいくつかであるため、私の意見を共有したいと思いました。 上記のいくつかは私が同意し、いくつかは同意しません。

基本的に、これを実現する必要があると思います。すべてのJuliaユーザーは、Juliaですでに実装されているように、高速な多次元配列（データストレージ用）を必要とします。 多くの/ほとんどのユーザーは線形代数にも興味があり、前述の配列はベクトルと行列に含まれるデータをパッケージ化する便利な方法です。 少数のユーザーは、一般的なテンソル（多重線形）代数を実行したいと思うでしょう。

問題は、これらの「裸の」配列を線形代数の数学的概念にどのように拡張するかです。 構文を通常の数学のようにするにはどうすればよいですか？ 人々はそのv ''！= vを快適にしますか？ 等

まず、線形代数を実行できるようにするために、配列をこれ以上悪化させたくないということです。 Vectorにデータを追加したり、Arrayに不要なテンプレート引数を追加したりする必要はありません。 線形代数を実行しないときはC / C ++と同じくらい速くなりたい（そして、できればC / fortranと同じくらい速くなりたい）。

2番目に認識すべきことは、完全な多次元テンソルの縮約には大量の追加情報が必要になるということです。 最大2次元のテンソルの場合、A_B'_C * D ...のような乗算を記述しますが、一般的なテンソルの場合、収縮を定義するグラフ（テンソルネットワーク図、または因子グラフ-同じことが言えます）を考える方が自然です。多くの異なる名前で）。 高次元テンソルの場合、すべてを追跡するために、裸の配列をラップし、ベクトル空間などでそれらを装飾することは理にかなっています。 これは、Jutho（および場合によっては他の人）が取り組んでいるパッケージなどで実行できます。 3次元テンソルでの 'の意味を考慮する意味はありません。permutedimが存在する場合、または専用のテンソルパッケージを使用している場合、誰もその関数を使用することに興味がありません。

コアユーザーは、行列を乗算したり、ベクトルを追加したりする必要があります。 彼らは行列を転置したいと思うでしょう。 彼らはまた、内積と外積を欲しがるでしょう。 好むと好まざるとにかかわらず、これらは双対空間と組み合わせて定義されます。 これらが実数と複素数に対して何であるかを知っており、それらを事前に定義しています。 そうです、実際の有限ベクトル空間の双対空間は基本的に同じように感じられるのは事実であり、これが問題全体を曇らせていると私は信じています。 現在の最大の問題は、適切な双対ベクトルがないことです。 それがなければ、ペンや紙のようにジュリアで方程式を「書く」ことはできません。これは大きな問題です。 さらに重要なことに、v '' = vがありません。これは非常に直感的ではありません。

人々は、内積または外積を実行するためのデュアルベクトルを作成することだけを望んでいるか、作成する必要があります。 コンパイラに次に遭遇したときに何をすべきかを指示するための単純な装飾ラッパー*は賢明な解決策であり、実行時のオーバーヘッドはゼロでなければなりません。 これらの双対ベクトル/共ベクトルは、インデックス可能、加算可能/減算可能、スカラーを乗算、ベクトル（スカラーを返す）、行列（コベクトルを返す）を乗算する必要があると思います-それだけです！ 複素数ベクトルの複素共役を明示​​的に実行することすらしません。これは、速度/メモリを向上させるために、内積、外積、インデックス付けなどに組み込むことができます。

型システムに複雑さが加わっていることを心配していません。 これは、ユーザーが高校や大学で数学を学んだときに数学をカプセル化するために必要だと思います。結合法則*（明確に定義されている場合）、v '' = v、「ブラ」と「ケット」の両方を持つ（Iここでは線形代数のディラック記法を使用しています）など。

ところで、このようなものがJulia 0.4で実装されている場合、私は気づいていません！ 私はまだ0.3.4の理解に取り組んでいます...

@andyferris 、私は一般的にこれらすべてに同意します。 ここでの私のM*v'がエラーである代わりに、コベクトルを生成し、 v*Mがエラーである代わりに、ベクトルを生成します。 私にとって、これは概念的には、その寸法が上か下かを知らないMに相当します。内積に対してv'*M*wまたはv*M*w'と書くことができ、どちらでも機能します。

跳ね返っている考えの1つは、行メジャー配列と列メジャー配列があり、 M.'が一方から他方に変更され、同様にv'がv行メジャーのバリエーションであるというものです。

@andyferrisに+1しTransposeおよびConjTransposeが必要だと思います。 @StefanKarpinskiの提案のポイント2に関しては、これらのラッパーをAbstractArrayオブジェクトのコンテナーに制限せず、型をAbstractArray型階層自体の一部にしません。 Transpose(x)は、式にx'を書き込んだ結果の型であり、 Transposeディスパッチすることで、式の残りの部分に応じて、評価を延期/遅延評価することができます。 *例99.9％で）。 ただし、行列因数分解オブジェクトや線形演算子などを定義するための他の型など、 AbstractArray階層の一部ではない可能性のある新しい型に対してもこの構文に意味を与えることができるはずです。

行列とベクトルの特定のケースについては、 M*v'のユースケースは実際にはわかりませんが、本質的に反対しているわけではありません。 重要なことは、それが基本的な期待（すなわち、ステファンの提案の終わりの規則2、4、5、6、および8）を満たすことです。

議論の主な最後のポイントは、おそらくスライスとの相互作用です。 行列の行スライスは自動的にTransposeますか？ ここでの私の投票は、そうではないAPLスライスルールに関するものです。

@Jutho 、動機は*結合性にすることです– A*(v'w)と(A*v')*w両方とも機能し、同じ結果を生成します。ポイント）。

(A*v')*wがA*(v'*w)と同じ結果を出すには、 A*v'がN=3配列である必要があります。 それはあなたが考えていたものですか？ 私はこれを完全に見逃しました。

OK、非常に興味深いです、私はいくつかのコメントがあります。

まず、コアユーザーに対応する必要があります。 基本的に、何よりもまずArray{T,n}をn次元ストレージとして使用することがその主要な機能です。 これは、線形代数については考えているが、ジュリア内のデータを操作したい人のプログラマーに意味を持たなければなりません。 このため、いかなる状況でも、配列スライスは共ベクトルを返すことはできません。 これは厳密に線形代数の概念であり、ベクトル空間とその双対（数値データや「フィールド」など）を定義できる特定のデータ型Tのみ適用されます。

私はAPLスライシングでどちらの方向にも行くことができました。 直感的には十分そうです。 それはタイプ安定であり、驚くべきことは何もしません。 線形代数を自己無撞着にするためにこの変更を行う必要はないと思いますが...それは素晴らしいかもしれません（それは重大な変更かもしれませんが）。 M[1,:]がサイズ1xnで、 M[:,1]がサイズn（nx1ではない）であることに不安を感じます...非対称すぎるようです...しかし、状況についての良い思い出になると思いますメモリに配置されます。 とにかく..この変更は、抽象データの保存と操作に意味がある場合にのみ行う必要があります。 私にとって、この変化は線形代数の議論と直交しています。

したがって、APLスライスルールを実装しなくても、意味のある線形代数を非常に簡単に回収できます。 あなたがしたい場合はiの番目の列ベクトルM呼んcolvec(M,i)としたい場合はiの目を行共同ベクトルMコールをrowvec(M,i) 。 iがタプルまたはベクトルの場合、タプルまたはベクトルまたは（共）ベクトルを返す可能性があります（これは、場合によっては並列化について推論するのに役立ちますか？）。 マトリックスが必要な場合は、通常のインデックス表記を使用してください。 APLスライスルールを使用する場合、同じことが*記号で行スライスと列スライスのアクションを区別するのに非常に役立ちます。 （ rowvec複素共役がどのように動作するかを考慮する必要があります）。

そうすれば、線形代数を実行している場合、すべてが理にかなっており、ユーザーはJuliaが実装する特定のスライスルールについて心配する必要がありません。 演算子'は、ベクトルと共ベクトル（装飾を変更するため）および行列（直接または遅延形式のいずれか）にのみ作用します。 私がいつも忘れているように見える固有分解から基底ベクトルを抽出する方法を覚えている方が簡単かもしれません。

*場合、Juliaの行列/ベクトル代数は、乗算演算子としての数学のように見え、感じられるように機能し、2つのベクトル、2つの共ベクトル、2つの行列などの間決して好きではないと思います。厳密には数学では、標準の乗算記号ではなく「\ otimes」記号（円内の時間記号）を使用して方程式を記述する必要があるため、 M*v'許可しないでください。 乗算記号を使用すると、その意味が明確に定義されていません。 行列の乗算は可換ではないため、 w*M*v' == v'*M*wことはできません。 繰り返しますが、 M*v'*v場合、 *結合性について話すのは意味がありません。 これは、2つの異なる乗算シンボルを必要とするinnerproduct(outerproduct(M,v'),v)として解釈するか、両方に*を使用することが理にかなっているスカラー乗算M * innerproduct(v',v)として解釈できます。 この式では、ブラケットが必要になる場合があります。または、コンパイラが意味のある演算の順序を検索する可能性があります（ここで、評価の最速の順序は、私が唯一の有効な評価の順序と見なすものでもあることに注意してください）。

ベクトル、共ベクトル、行列を使用すると、標準的な数学と一致する代数システムを作成できます。 2つのベクトル、2つの共ベクトル、または2つの行列の間で外積を実行する場合は常に、本質的に多重線形代数または一般的なテンソル代数に移行します。 ここでは、新しいシンボルを使用してkron(M,N)ように乗算する行列とベクトルを作成できます。 または、完全な多重線形代数パッケージを使用するようにユーザーに要求することもできます。 または何でも...元の質問の範囲を超えているようです（14か月前、ところで...）

要約すると、ここでは4つのほぼ完全に異なることが起こっていることがわかります。

1. APLスライスルールを使用して、任意のデータのArrayのスライスを改善します。
2. いくつかの簡単な概念を追加することにより、ジュリアの線形代数をより直感的で数学と完全に一致させます：コベクトルと行列からベクトルとコベクトルを抽出する方法、およびコベクトル、行列などの間の操作。多くのユーザーはコベクトルが存在することに気付かないかもしれません。 1xnおよびnx1行列を使用すると、引き続き期待どおりに機能し、ベクトルは同じように動作します。
3. 速度を上げるために、コベクトルによく似たラッピング型を使用して、 transpose 、 conjなどの遅延評価を実装しますが、行列も同様です。
4. 汎用テンソルパッケージを開発し、場合によってはそれを標準ライブラリに追加します。

おそらく最初のものだけが重大な変更になるのでしょうか？ その他は、現在の機能を改善または追加します。 それらはすべて多かれ少なかれ独立して実装することができ、おそらくすべて行う価値のあることです。 （PS APLスライスが必要な場合は、ジュリアが「大きく」なりすぎてパッケージが多すぎるなどの前に、

ええ、申し訳ありませんが、 M*v'を許可するという私の提案は、製品を関連付けるさまざまな方法が完全に異なる形状を生成するため、実際には意味がありません。 ですから、これを変えるつもりなら、私の最初の提案が道だと思います。 これまでのところ、これはAPLスライス動作との最良の組み合わせのようです。 もちろん、APLスライス動作が必要かどうかは、より高いレベルの考慮事項です。

いくつか言いたかったのですが、一粒の塩と一緒に持っていってください。 彼らはただの意見であり、私は私のものがあまり重要ではないことを知っています。 しかし、 @ andyferrisのコメントを読んでいた気づきました。 線形代数については知らないが、Juliaでデータを操作したいプログラマーにとっては意味があるというコメントには同意できないと思います。 プログラマーは数学プログラムを書くべき聴衆ではないと思います。 プログラマーがデータを操作したい場合、それを可能にする多くの言語があります。 ジュリアはコンピューティングのための言語であり、高度な技術的コンピューティングを可能にするはずです。

@ esd100確かに、私はそのことを考えました。 しかし、ジュリアと一緒に、私たちは_貪欲になりたいと思っていました...多くの目的に応え、多くのことに優れていることを望んでいました。 非数値データを操作することには、真の科学的理由があるかもしれません。 より一般的なプログラミングをしたいジュリアユーザーである現在または元の科学者がいるかもしれません。 私の以前のポイントは、転置/活用について話すための追加のフィールドを与えることによって、 Array遅くしたり、より多くのメモリを使用したりするべきではないということ

APLスライスを実行する場合、行スライスまたは列スライスのいずれかが同じオブジェクトを返す必要があります。 問題は、APLスライスなしで、 M[1,:]が返されるのに最適なものは何でしょうか。 ええと、 M[1,:,:,:,:]がArray{T,n} M[1,:,:,:,:]返す場合、 M[1,:]がcovector{T}返すと、みんなを混乱させると思います。 M = zeros(3,3,3)を許可し、現在1x9の行列を返すM[1,:]を呼び出すとどうなりますか？ これも共ベクトルにする必要がありますか？ MがArray{String,3}どうなりますか？

私には、これは非常に驚くべき混乱を招くように思われるでしょう。 また、将来発生した場合、APLスライスの変更と一致しません。 したがって、私は線形代数の目的で新しい関数rowvec(M,i)とcolvec(M,i)を追加することを提案していました。 それは理想的ではなく、新しい関数を追加します...しかし、少なくとも線形代数の目的でそれらが何を返す必要があるかは明らかです。 多重線形代数に対応しようとはしていませんが、一般的な配列の優れたプロパティと線形代数の優れたプロパティ（およびコベクトル型）を備えていると私が考えることができたのはそれだけでした。 行列からコベクトルを抽出するためのより良い表記法があれば、それもいいでしょう！

@ esd100 ：Juliaが設計されているのはプログラマーだと確信しています。 科学計算はジュリアスの強みですが、汎用プログラミング言語としてそれを使用する多くのジュリアユーザーがいます。

テンソル要件をコンテナ要件から分割する必要があるという@andyferrisに同意します。

スレッド全体を読んでいないと、私の個人的な問題は、3D配列A （断層撮影データなど）があり、

imagesc( data[1,:,:] )

これは動作しません。 IMHO data[1,:,:] 、 data[:,1,:] 、およびdata[:,:,1]は2D配列（またはサブ配列）である必要があります。 現在、この問題を解決するために、自己定義のsqueeze関数を使用しています。

繰り返しますが、これは私の意見であり、私が行動から遠く離れていることを考えると、非常に重要ではありません。 アプリケーションを開発するときは、それを導く一連の設計原則が必要だと思います。 ビルダーは、その目的とアイデンティティについて明確で統一されたメッセージを送信する必要があります。 高速で直感的で洗練された技術的なコンピューティングプラットフォームを開発することが目的であり、それがJuliaの強みである場合は、それに固執します。 一般的なプログラマーの聴衆にその目的を適合させようとして、混合信号を送信しないでください。

重要なのは、純粋に科学的または数学的アプリケーションの場合でも、いくつかの矛盾する解釈があります。たとえば、ベクトルと行列を使用して表すことができるいくつかの数学的オブジェクトがあるため、あまり具体的な選択をするべきではありません。

特定の一連の規則に従って特定の分野のニーズを満たすために、専用のパッケージを用意することをお勧めします。

@jutho私の

これは非常に簡単です。 ほとんどのJuliaユーザーにとって重要な機能はBaseに属しています。 より特別な機能はパッケージに属します。

もちろん、ここに線を引くのは簡単ではありません。 しかし、何かをベースに入れる最良の方法は、多くの人がこれをテストできるようにパッケージを作成することです。 Baseに導入されたさまざまなコア機能は、最初にパッケージで開発されました。

@ esd100 、あなたの質問を完全には理解していません。 結局、科学言語が提供すべきものは、科学で使用される典型的なオブジェクトで表現および計算するためのデータ構造と方法です。 ただし、特定のデータ構造は、異なる数学的構造を表すのに役立つ場合があり、同じタイプのオブジェクトには異なる表現が役立つ場合があります。 したがって、固定された数学的構造をデータ型に関連付けることは、一部の分野では制限が厳しく、他の分野では複雑すぎる可能性があります。 したがって、これはJuliaベースでは追求されるべきではなく、1つの分野のニーズにのみ対応しようとする特定のパッケージによって追求されるべきです。

現在の議論に関して、ベクトルと行列を扱うすべての人は、ベクトルを転置し、v ^ T * w =スカラーを持つ可能性を期待します。 しかし、これらのベクトルと行列は、さまざまなものを表すために使用される可能性があり、これはおそらく分野/分野に依存します。 上記の投稿で、v ^ Tが実際の共ベクトルではない可能性がある場所の例を示しました。

2015年1月11日には、午前18時10分で、ESD100 [email protected]書きました：

@jutho https://github.com/jutho私の直感はあなたが正しいということですが、パッケージが「より良い」というあなたの結論の根拠は何ですか、そしてどの代替案と比較して？

—
このメールに直接返信するか、GitHubhttps ： //github.com/JuliaLang/julia/issues/4774#issuecomment-69501771で表示して

これは非常に簡単です。 ほとんどのJuliaユーザーにとって重要な機能はBaseに属しています。 より特別な機能はパッケージに属します。

それほど単純ではないと思います。 たとえば、Baseにはベッセル関数があり、ほとんどのJuliaユーザーにとってそれらが重要になる可能性はほとんどありません。 それらがBaseにあることができる理由は、ベッセル関数が何であるかについて1つの合理的に普遍的な標準があり、誰もそれらの名前を他の何かに使用したり、何か別のことをすることを期待したりしない可能性があるためです。

注意深い（冗長と言う人もいるかもしれませんが）命名規則により、Mathematicaはコア言語で4000を超える関数を配置でき、パッケージをロードする必要がほとんどないので非常に便利です。 対照的に、Python / Sageを使用している場合、1つのファイル/ノートブックが上部に200個の関数を明示的にインポートすることは珍しくありません（追跡不可能な「from ___ import *」構文を回避します）。 組み込みではない関数を使用する必要があるたびに、次のような追加の手順を実行する必要があります。

（1）そのファイルですでに使用したかどうかを覚えておくか、テキスト検索を行って確認します（名前が他の部分文字列の場合は単語全体に制限します）
（2）次のいずれか：（a）インポートをすぐに追加し、思考の流れを失い、再び見つけます。 または（b）何かを行った後、別のことをメモリに保持して、インポートを追加することを忘れないようにしてください
（3）あまり一般的でない関数の場合、おそらくそれがどのパッケージに含まれているかを調べる必要があります

これは迷惑で衰弱させる可能性があります。 したがって、ベッセル関数のように、標準と見なされるものはすべて、つまり名前の競合や混乱を引き起こさないものは、多くの人が使用するかどうかに関係なく、Baseに含める必要があると思います。 確かに線形代数。

トピックに戻ると、機能のいくつかのレイヤーについて話してきました---意味的に裸のコンテナーとしての配列（ Base.AbstractArray実装されている）から、上下のセマンティクスを持つデカルトテンソルオブジェクト（私の説明による）までAbstractTensorArray提案、ベクトル空間にマップされたインデックスを持つより一般的なテンソルオブジェクト（ @JuthoのTensorToolboxのように）---一般性を高め、最適化の可能性を減らします。

ユーザーがこれらのレイヤー間を簡単に移行できることが重要だと思います。特に、ユーザーが最初に実際に必要な一般性のレベルを「知らない」可能性があるためです。 簡単な例として、@Juthoは指摘@jdbatesの画像処理例では、ユーザが非常によくように一方向と別の方法で色空間における処理画像座標として、別個のジオメトリにインデックスの異なるサブセットを関連付けるかもしれません。 ただし、これらの1つだけを幾何学的に使用し始めた場合は、それぞれを独自の幾何学的に使用できる、より一般的な表現にアップキャストすると便利です。 一般性の各レベルで開始する追加の関数（または関数呼び出しパターン）が適切なデフォルトを使用する場合---たとえば、 AbstractTensorArrayのアップ/ダウンインデックスとニュートラルインデックスを単一のデフォルトのデカルトベクトル空間にアップキャストし、それぞれ「シーケンス」スペース---その後、ほぼシームレスになります。 機能の下位層のユーザーは、必要になるまで上位層を知ったり気にしたりする必要はありません。

明確で予測可能なこの部分---関連するユーザーにとって---階層がどうあるべきかは、合理的にBaseに入る可能性があります。 本当の問題は、配列演算、線形代数、テンソル代数のいずれの場合でも、このタイプの機能のユーザーが別の方法を期待または望んでいる可能性はどのくらいあるでしょうか。

多くの人が、Pythonランドで何かを行うために必要なインポートの数のばかげた粒度を嫌っていますが、それほどの長さになることを提案している人はいないと思います。

しかし、いくつかの使用例では、多数の依存関係とライブラリの肥大化は望ましくないという重要な議論があります。Julia言語では、Fortranランタイムライブラリをコンピュータにインストールする必要はありませんが、現時点では、Julia標準ライブラリをインストールする必要があります。実行したいコードは、線形代数（またはBessel関数、またはFFTなど）を実行しています。 これはすべて＃5155やその他の問題で十分にカバーされていますが、「デフォルトでインストールされている」と「機能に最低限必要なもの」は、最終的には異なるモジュールのセットに分離する必要があります。

トニーに感謝します。 さらに、私たちのパッケージシステムでは、複数をグループ化するパッケージのような「ツールボックス」を使用しても問題はありません。 @reexportマクロを使用すると、これはうまく機能します。

しかし、別のポイントがあります。 パッケージ内では、アイデアを前進させるのがはるかに簡単です。 何かを変えたいのなら、それをするだけです。 ベース1内では、はるかに制限されています。

パッケージのパッチワークを使用すると、独立性が高まりますが、プラットフォームが断片化され、ナビゲートがより困難になるようです。 より統一された一般化された構造を使用すると、分野間の相互作用と新しいドメインの探索が合理化および促進されるようです。

ベクトル*行列を実行するための現在最も慣用的な方法は何ですか？
例えば、私が持っていると言うX形状で(K, N)とb形状と(K,) 、と私は掛けるたいbに長さ(N,)ベクトルを取得するために残しました。
BLAS.gemv('T',1.0,X,b)に電話しますか
またはreshape(b'*X,size(x,2))
どちらも少し醜いです。

私はあなたがX'bをすることができると思います

2015年3月13日午後五時15 GMT-04：00 joschu [email protected] ：

ベクトル*行列を実行するための現在最も慣用的な方法は何ですか？
たとえば、形状（K、N）のXと形状（K、）のbがあり、必要な場合
左側のbを掛けて、長さ（N、）のベクトルを取得します。
BLAS.gemv（ 'T'、1.0、X、b）を呼び出しますか
またはreshape（b '* X、size（x、2））
どちらも少し醜いです。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-79405868 。

ええ、私はそれがXのコピーをトリガーすると思っていました。
しかし、 @ timeは、メモリ割り当てに基づいて、コピーがないことを示しているようです

julia> X = rand(1000,1000); y = rand(1000);

julia> <strong i="8">@time</strong> y'X;
elapsed time: 0.00177384 seconds (15 kB allocated)

julia> <strong i="9">@time</strong> X'y;
elapsed time: 0.000528808 seconds (7 kB allocated)

'の構文解析を行うので、 X'yはAc_mul_B(X,y)になり、
あなたが提案したのと同じBLASコール。

2015年3月13日午後五時28分GMT-04：00 joschu [email protected] ：

ええ、それがXのコピーをトリガーすると思っていましたが。
（しかし、 @ time https://github.com/timeは、ないことを示しているようです
コピー、メモリ割り当てに基づく

ジュリア> X = rand（1000,1000）; y = rand（1000）;

ジュリア> @time y'X;
経過時間：0.00177384秒（15 kB割り当て）

ジュリア> @time X'y;
経過時間：0.000528808秒（7 kB割り当て）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-79421713 。

信じられないかもしれませんが、このスレッド全体の記述は具体化に近づいています。

最後のポイント：誰かがそれを考慮しましたか？」 実際には 'とはまったく異なる動物である可能性がありますか？ 後者はデュアルであるための正しい構造を持っていますが、。 基になるフィールドが実数でない場合はそうではありません。 割り当てるのはおかしいですか。」 転置の「すべてのインデックスを逆にする」概念を転置し、双対性のすべての概念を 'に予約します。これにより、「面白い行ベクトル」/エルミート共役が生成されますか？

いずれにせよ、 conj(transpose(x))はctranspose(x)と同等である必要があると思います。

上で論じたように、 transposeとctransposeが作成するラッパータイプのいずれにも、 dualなどの特定の数学的概念を含む名前が付けられることを願っています。 Juliaなどの科学言語は、一連の有用なデータ構造を提供し、一般的な操作を実装する必要がありますが、厳密な数学的構造をそれに関連付けるのは間違いだと思います。これは、一部のアプリケーションには適切でなく、その他。 これらのデータ構造と演算を使用して、アプリケーションに数学演算を実装するのはユーザーの責任です。 z.' * A * zがスカラーを返すアプリケーションは確かにあります。ここで、 zは複素ベクトルであり、 Aは行列ですが、これは内積や双対とは関係ありません。ベクトル。

@jutho z.' * A * zユースケースを教えていただけますか？

z1とz2が2つの複素ベクトルZ1とZ2の表現である場合（たとえば、ケーラー多様体の接空間のホロモルフィック部分の接線ベクトル）およびaは、2つの共変インデックス（たとえば、ケーラー多様体の複素数（2,0）形式）とA(Z1,Z2) = z.' * a * zを持つテンソルAの行列表現です。

ここで強調するのは、ジュリアオブジェクトz1 、 z2 、およびaは、（選択された基底/調整に関して）特定の数学的オブジェクトの_表現_を形成するだけであるということです。データ構造に対する操作は、これらのデータ構造が何を表しているかを知らない限り、数学演算に一意に関連付けることはできません。

@juthoありがとう。 表現についてのあなたの指摘はよく理解されており、この議論では何度も表現されてきました。 ベクトルと行列の最小インターフェイスを見つけて、その最小インターフェイスが配列の最小インターフェイスと根本的に互換性がないかどうか、およびユーザー定義の抽象データ型に何をオフロードできるかを確認しようとしています。

この時点で、私は@StefanKarpinskiの提案に全面的に賛成です。これも、上記の@andyferrisによってほとんどエコーされて

1. APLスタイルのインデックス作成
2. v 'はある種のCovectorまたはTransposeタイプを与えます

他のすべては詳細です。 row(M,i) col(M,i)関数とM[i,:].'が必要になると思いますか？ IIUC、 M[i,:]'は、この場合は望まないconjますか？

はい、前回書いたときのAPLスタイルのインデックス作成の良さを十分に理解していなかったことを付け加えておきますが、今ではその変更を全面的にサポートしています。 これにより、双対ベクトルがさらに魅力的になり、 row / col機能します。

それ以来、実装を試してみましたが、最も混乱したのは、行列から抽出されたコベクトルが共役であるかどうかでした…

マトリックスのリテラル値を取得したいと思います。 ディラック記法を使用して、（任意の）行列M = sum_i | i>を展開します。例：[0,0,1、...、0]、抽出したいU row(U,i)' = col(U’,i)を取得します。これは、固有分解から左右の固有ベクトルを抽出するのに最適です。

アンディ

2015年3月15日には、午前9時36分pmに、ジェフBezansonの[email protected]は書きました：

この時点で、私は@StefanKarpinski https://github.com/StefanKarpinskiの提案に全面的に賛成です。これも、上記の@andyferrishttps ：//github.com/andyferrisによってほとんどエコーされています。 特に

APLスタイルのインデックス作成
v 'はある種のCovectorまたはTransposeタイプを与えます
他のすべては詳細です。 row（M、i）関数とcol（M、i）関数を追加すると便利な場合があります。 それ以外の場合、行をコベクトルとして抽出するには、M [i 、：]が必要になると思います。 ？ IIUC、M [i 、：] 'は、この場合に望まれない接続詞を実行しますか？

—
このメールに直接返信するか、GitHub https://github.com/JuliaLang/julia/issues/4774#issuecomment-81228816で表示して

これに取り組み始めるボランティアはいますか？ たとえば、 @ mbauman 、 @ jakebolewskiは、私が驚いたことに、このスレッドにはまだ含まれていません:)

変更が必要なものをすべて見つけるのは面倒かもしれませんが、インデックス作成の動作に対する基本的な変更はそれほど悪くないはずです。 おそらく、 @ jiahaoと@andreasnoackは、

これを進める前に、9、8のコメントは必要ありません。

私はそれを手伝うことができます。

私たちはかなり近いです

関連するコメントとして、 TransposeとCTransposeラッパータイプがある場合、それらもプレーンなConjugateラッパータイプである必要があります。たとえば、 conj(A)は次のようになります。また怠惰です。 行列にBLASを乗算する場合、特別なサポートがないため、これはあまり役に立ちません（BLASのCはエルミート共役を意味します）が、完全なJulia BLAS実装がある場合は、サポートすることもできます。 conj(A)*B明示的な活用なし。

私は、以前よりもベクトル転置を真剣に受け止めているように感じます。

おそらく、 @ andreasnoackと@simonbyrneは、＃6837を再検討する必要があるかどうかを教えてくれます。

Transpose{Array} <: AbstractArrayがあってはならないという@simonbyrneに同意します。

その他の一般的な考え：

• 現在、外積の計算には、「末尾のシングルトンディメンションを自動的に追加しない」ルールの例外が含まれていることに気付きました。 uサイズが(n,)場合、 u * u'は(n,) x (1, n)含む計算です。 この積は、最初の引数を(n, 1)に自動的に再形成しない限り、行列乗算の通常の規則を使用して計算することはできません。
• MATLABインデックスセマンティクスの「末尾のシングルトン次元を自動的に追加する」ルールは、「転置がすべての次元を逆にする」ルールと基本的に互換性がありません。 前者の規則では、形状(n,)配列は、形状(n,1)や形状(n,1,1)などの再形成された配列と意味的に同一です。ただし、転置によってすべての次元が反転する場合は、結果の配列の形状は(n,) 、 (1, n) 、および(1,1,n)であり、末尾のシングルトンの追加のみが許可されている場合、これらは同等ではありません。 これを論理的に極端に考えると、配列の転置は任意の数の_leading_シングルトンを持つ可能性があるため、論理的に一貫性のないあいまいな形状になります。

また、文献調査を行い、いくつかの興味深いAPLの歴史​​を明らかにしました。 私たちがAPLインデックス規則と呼んでいるものは、Iversonの1962年の本にはありませんでしたが、APL \ 360（1968; APLの最初の実装）には存在していました。 ただし、APL \ 360は、スカラーと1ベクトルを混同しました。これは、（Haegi、1976）まで文献で認識されていなかった不整合です。 多次元配列の形式的セマンティクスに関する議論は、ブラウンの博士論文（1972;後にAPL2を設計）に最初に登場し、それらのセマンティクスを形式化する一連の作業に拍車をかけました。

APL2につながる開発の優れた調査は次のとおりです。

• Karl Fritz Ruehr 「APLの拡張に関する調査」。 APLに関する国際会議の議事録、APL '82、277〜314ページ、ニューヨーク、ニューヨーク、米国、1982年。ACM。

索引付け規則に注意が払われていることについて、文献で注目に値するのは次のとおりです。

• T.もっと。 「配列の理論のための公理と定理。」 IBM Journal of Research and Development、17（3月）：135–175、1973。
  
  
  
  • Quineの公理的集合論を使用して多次元配列のセマンティクスを形式化する巨大な書物で、APLの文献で「浮動配列」と呼ばれるものを構築するために、自己完結型集合の概念を使用してスカラーをランク0配列とどのように融合できるかを示しています。 （[1] == 1、[1]！= 1の「接地配列」とは対照的。1980年の修士論文でのSheilaM。Singletonによる後の研究では、Moreの配列理論も接地配列の記述に適合できることが示されました。）
  
  
  • さらに、配列のセマンティクスをガイドするための重要なルールとして、スカラーを返す内積についても言及しています。
  
  
  • さらに、一般的な多次元配列の「アップ/ダウンネス」の処理の複雑さをほのめかします。
    
    「Vを体上の多元環とするn次元ベクトル空間とします。反分散と共分散の考慮を無視すると、V上の価数qのテンソルは、長さqのリストVV ... Vの直積のベクトルへの多重線形マッピングです。空間。Vに底がある場合、V上の価数qのテンソルは、それぞれ長さnのq軸上の配列である_componentテンソル_で表すことができます。」
  
  
• G.ルイス。 「APLの新しいアレイインデックスシステム」、APLに関する第7回国際会議の議事録-APL '75、234-239、1975。
  
  
  
  • このペーパーは、インデックス作成操作でインデックスタプルをAPLのファーストクラスオブジェクトとして提唱した最初の論文であり、インデックスタプルの各ランクに沿った体系的なデカルト積によってインデックス作成の結果の一貫した構築を実現できることに注目しました。
  
  
• ハンスRヘギ。 「ツリーのようなデータ構造へのAPLの拡張。」 ACM SIGAPL APL Quote Quad、7（2）：8–18、1976。
  
  
  
  • この論文は、スカラーと1配列を混同した、古典的なAPL \ 360の不整合について不満を述べ、APLインデックスルールではこの混同が成り立たないようにする必要があると主張しました。
  
  
  • この論文には、1975年のルイスと非常によく似た構造も含まれています。 仕事は独立しているようです。
  
  
• JAGerthとDLOrth。 「APLでのインデックス作成とマージ。」 APLに関する国際会議の議事録、APL '88、156〜161ページ、ニューヨーク、ニューヨーク、米国、1988年。ACM。
  
  
  
  • APLインデックス付けルールは、インデックス付けを、インデックスセットを値セットにマッピングするブロードキャスト操作と考えることで正当化できることに注意してください。 この機能的解釈は、当然、ランク保存規則とルイスとヘギのデカルト構造を示唆しています。
  
  

また、「末尾のシングルトンディメンションを追加できる」ルールがないと、アイデンティティに従わない

左側はスカラー（トレースの定義による）であり、右側は形状(1, n) x (n, n) x (n,) = (1,)です。 逆に、このアイデンティティは、ベクトル転置セマンティクスを選択するための指針と見なすことができます。 重要な点は、最初のIDを定義するトレース操作の循環プロパティです。 トレース内の量は、スカラーまたはマトリックスのいずれかである必要があります（ベクトルのトレースは定義されていません）。 Avv'はすでに明確に行列です： (Av)v'とA(vv')は同じ結果を生成します。 しかし、2番目の量からも、 v'Avは行列またはスカラーでなければなりません。 （スカラーの場合、2番目のIDも保持されます。） v'Avは、「末尾のシングルトン次元を追加できる」ルールがアクティブな場合にのみ1ベクトルになります。この場合、透過的に1x1行列に再形成できます。

したがって、トレースを定義する場合は、必然的に、外積vv'および2次形式v'Avの許容形状に制限が課せられます。

@jihao ：あなたが私たちに対して何を主張しているのかよく

あなたの議論のいくつかは、転置をすべての次元を逆転させるとは考えられない立​​場を強化するために取ることができると思います（列ベクトルは列ベクトル、またはおそらく任意の数の先行シングルトン次元を持つ配列に転置されます）。 行列代数との一貫性を保つには、代わりに最初の2つの次元を交換するものと見なす必要があると思います。 そうすれば、あなたが述べている矛盾のいくつかは消えると私は信じています。 うまくいけば、転置時にシングルトン次元を追加しないと、残りは消えます（コベクトルの最初の次元がないことはカウントされません）。

上記の私の一般的なコメントは、これらのルールを支持することではなく、配列インデックスルールの設計空間と線形代数のアイデンティティとの相互作用を描写するのに役立つことです。

「末尾のシングルトン次元を追加できる」ルールはMATLABで使用され、（@ alanedelmanによると）多次元配列をサポートするために導入されました。 MATLAB配列で使用されるインデックスからオフセットへの計算は、 sub2indで定義されます。これは、末尾の1をいくつスローしても、同じ線形インデックスを返します。 さらに、MATLABのマトリックスインデックス作成ドキュメントには、インデックス作成操作

1に等しい末尾の添え字を含まない、Bに指定された添え字の数は、ndims（B）を超えません。

より正式には、次のように述べることができると思います。

配列を入力として受け取る操作の場合、 (n,) -arrays、 (n,1) -arrays、 (n,1,1...)配列は、これらの操作の有効な引数であるという点で、すべて同じ等価クラスにあります。 （ n=1場合、同値類にはスカラーも含まれます。）

例：

• A*bおよびA\bここで、 Aは行列であり、 bはベクトルまたは行列（ n x 1行列と同じセマンティクス）です。
• hcat(A, b)ここで、 Aは行列で、 bはベクトルまたは行列です。

外側の製品の例を除いて、ほとんどの場合、Juliaにはこの「末尾のシングルトンディメンションルールを追加できます」ルールがありません。 他にもあるかもしれませんが、今は思いつきません。

Transpose{A<:AbstractArray}がAbstractArrayサブタイプでない限り、問題はないと思います（ただし、皆さんほど考えていないので、何かを見落としている可能性があります） ：
と

typealias AbstractVectorTranspose{A<:AbstractVector} Transpose{A}
typealias AbstractMatrixTranspose{A<:AbstractMatrix} Transpose{A}
typealias AbstractTMatrix Union(AbstractMatrix, AbstractMatrixTranspose} 

（そして同様にCTranspose ）

AbstractVectorTranspose * AbstractVector = Number
AbstractVector * AbstractVectorTranspose = AbstractMatrix
AbstractVectorTranspose * AbstractTMatrix = AbstractVectorTranspose
AbstractTMatrix * AbstractVector = AbstractVector
AbstractTMatrix * AbstractTMatrix = AbstractTMatrix

唯一の未解決の質問は、 AbstractTMatrix最初のサイズが1の場合にAbstractVector * AbstractTMatrixをサポートする必要があるかどうか、またはAbstractVector * AbstractVectorTransposeで十分かどうかです。

また、新しい型システムは、これらのtypealiasとunionいくつかをもう少し注意深く表現するのに役立つかもしれません。

また、たとえばv.'*Aが(A.'*v).'として計算される場合、 A自体がたとえばA=B'あれば、 Conjugateラッパーの必要性がポップアップします。 。

Transpose{Array} <: AbstractArrayがあってはならないという@simonbyrneに同意します。

そこで詳しく説明していただけますか？ https://github.com/JuliaLang/julia/issues/4774#issuecomment -59428215での意見は、CoVectorはAbstractVectorのサブタイプであってはならないというものだと思いましたが、 Transpose{Matrix} <: AbstractArrayがないのは少し奇妙に思えます。

CoVectorは、 Vectorが列行列としてMatrix変換され、 CoVectorことを除けば、ほとんどVectorように動作するはずです。 CoVectorは、行行列としてMatrix CoVector変換されます。

これは、コベクトルへのインデックス作成が行行列へのインデックス作成と同じように機能することを意味すると思いますか？

それは興味深い考えです。 転置/共ベクトル型で_leading_シングルトン次元のみがドロップされた場合、物事はより簡単またはより複雑になりますか？

（私は興味を持ってこの問題をフォローしてきましたが、私の線形代数は十分に錆びているので、貢献する資格があるとは感じていません）。

@mbauman ：

転置/共ベクトル型で先頭のシングルトン次元のみが削除された場合、事態はより簡単またはより複雑になりますか？

任意の数の先行シングルトン次元を許可すると、配列インデックスは適切に順序付けられなくなり、「最初の」次元のようなものはなくなります。これは、公理として適切な順序付けを行うのに十分なほど奇妙です。

@tkelman ：

＃4774（コメント）の意見は、CoVectorはAbstractVectorのサブタイプであってはならないというものだと思いましたが、Transpose {Matrix} <：AbstractArrayがないのは少し奇妙に思えます。

この問題は、配列セマンティクス（＃10064を参照）を線形代数セマンティクスから分離し、混合されている場所を探すことに関するものであることが完全に明らかになりました。

• 配列のセマンティクスは、size、length、getindex、setindex、hcat、vcat、reshape、rot90などの関数によって定義されます。
• 線形代数のセマンティクスは、+、-、*、/ 、、 '、trace ..などの関数によって定義されます。

cat関数をAbstractArrayの基本的なインターフェイスの一部として定義すると、連結動作が異なるため、 Transpose{<:AbstractArray}は明らかにAbstractArrayはありません。 。 形状とインデックス付けのみが重要なインターフェイスの一部であると考えると、状況はあまり明確ではありません。

我々はの重要なインタフェースの一部として連結を必要とする場合はAbstractArray 、正当化することも容易になる理由のようなタイプのSymTridiagonalされていないAbstractArray以上の連結演算以来の、 SymTridiagonalのようなS [SymTridiagonal(randn(5), randn(4)) randn(5)] 、現在定義されていません。

@toivoh ：

これは、コベクトルへのインデックス作成が行行列へのインデックス作成と同じように機能することを意味すると思いますか？

Transpose{Vector}インデックス作成動作は、通常のVectorと同じである必要があることを示唆するIDがあります。 数値型の場合、 v[1]はv' * e₁ = v ⋅ e₁と同じ結果を生成し、 v[1:2]はv' * [e₁ e₂]と同じ結果を生成することを考慮してください。ここでe₁は正規基底Vector{Int} [1, 0, 0, ...]およびe₂は[0, 1, 0, 0, ...]です。 インデックス付け、内積、転置に関連するこれらのアイデンティティを保持する必要がある場合は、次のように主張できます。

(v')[1] == (e₁' * v'') == (v' * e₁)' == (v ⋅ e₁)' == conj(v ⋅ e₁)* = conj(v[1])

（最初のステップは新しい公理であり、4番目のステップはスカラーの転置がノーオペレーションであるという事実を利用します） Transpose{Vector}へのインデックス付けは本質的に転置を無視し、 CTranspose{Vector}へのインデックス付けを行います

この問題は、配列セマンティクス（＃10064を参照）を線形代数セマンティクスから分離し、混合されている場所を探すことに関するものだと私は思います。

• 配列のセマンティクスは、size、length、getindex、setindex、hcat、vcat、reshape、rot90などの関数によって定義されます。
• 線形代数のセマンティクスは、+、-、*、/ 、、 '、trace ..などの関数によって定義されます。

その観点に+1し、 Transpose <: AbstractArray持たないようにします。 また、covectorにインデックスを付ける場合は、単一のインデックスを使用する必要があります。そうしないと、covector * vector（単一のインデックスで縮小）の結果がスカラー（インデックスがゼロのオブジェクト）になることがないためです。

@jihao ：なぜ私たちが必要なのか、欲しいのかわかりません

(v')[1] == (e₁' * v'')

新しい公理として。 コベクトルが行行列としてインデックス付けされる場合でも、線形インデックス付けにより、上記と同じ結果が得られると思います。

そして、線形代数に関係するものとして共ベクトルを見ることに+1。

しかし、 SymTridiagonalとの連結を定義すべきではない理由はありませんよね？

配列の@toivoh線形インデックス付けは、最初に配列をベクトルに再形成し、次に新しいベクトルにインデックスを

線形インデックス付けはストレージの順序に関するものだと思いましたが、ベクトルの線形インデックス付けには他に賢明な順序はありませんよね？ （スペルミスについては申し訳ありません。）

記憶には、独特の賢明な横断順序はありません。 Fortran配列の場合でも、要素を列メジャー、行メジャー、または逆列メジャーの順序で格納することを選択できます（これは元のIBM Fortran Iコンパイラーが行ったこととまったく同じです）。 さらに、配列として使用でき、トラバーサル順序のオプションがさらに多い試行などの他のデータ構造（＃10064を参照）があります。

ベクトルと行列についても同じことが言えます。 線形インデックスは、列行列とその転置に対して同じ順序で（そして列ベクトルの場合と同じように）要素にアクセスするので、なぜコベクトルが異なる必要があるのですか？ もしそれが違うとしたら、コベクターのインデックス付けをまったく定義しないはずだと思います。

@toivohはい、同じ定義が通常の配列にも

Transposeオブジェクトのインデックス作成

線形代数関数の多くの純粋なJulia実装は、転置にインデックスを付けたいと思うでしょう。 関係する2つの行列の可能なケース（通常、転置、ctranspose、conj？）を区別する必要がなく、通常の行列として扱う場合は、純粋なJulia行列乗算（非BLAS数型の場合）を簡単に記述できます。 キャッシュを無視する方法を試して、ある程度ローカルなメモリアクセスパターンを取得することができます。

そうだね。

@Jutho ：同意します。 そして、そこに収まるように、コベクトルは行行列のようにインデックスを付ける必要がありますよね？

@toivoh 、もしあなたが彼らが前に余分なインデックス1を持っているべきだということを意味するなら、私は同意せず、それが私の声明によってどのように暗示されているのかわかりません。 私はマトリックスマトリックス製品についてのみ話していました。 Matrix * vectorまたはcovector * matrixは、メモリアクセスパターンが異なるだけでなく、戻り値の型（Matrix_vector = vectorまたはcovector_matrix = covector）も異なるため、異なる関数定義を必要とする異なるメソッドであるため、これらのものを混ぜないというジュリアの非常に実用的な理由。

一般に、私は、N次元配列にインデックスを付けるときにインデックス1を追加する機能や、たとえばVecOrMatタイプのエイリアスの大ファンではありません。 これにより、ずさんなプログラミングが可能になりますが、それが間違いを犯したり、他の間違いをより遅く検出したりするのを容易にする理由でもあります。 多重線形オブジェクトとして使用している場合は正確なNインデックスを使用し、テンソル積でベクトルとして使用している場合は線形インデックスを使用して、N次元配列をinexする2つの便利な方法しかありません。スペース（たとえば、そのような2つの配列を追加したり、スカラーを乗算したりする場合）。 私の使用方法にはそれで十分ですが、それは他の人に限定されていることを受け入れることができます。

@Jutho ：

これが私たちがやろうとしていることを説明し、いくつかの公理を与える試みです：

出発点は行列代数（行列のみに基づく）であるというかなり明確なコンセンサスに到達したと思います。 ほとんどの操作では、純粋なマトリックス設定での動作がわかっています。

私たちがやろうとしているのは、純粋な行列設定を一貫した方法で拡張および改良して、真のスカラーとベクトルも持つようにすることです。一貫性のために必要と思われるため、コベクトルです。

これがスカラーとベクトルの私の見方です（純粋な行列の観点から見た場合）：スカラーは行列であり、そのタイプによって1 x 1に制約されます。ベクトルは、そのタイプによって次のように制約される行列です。 be nx 1（コベクトルは、そのタイプによって1 x nに制約される行列であると以下で議論します。）この観点から、2つの公理を与えることができます:(以下ではあまり正式には説明されていません）

• 拡張：行列から行列への関数を考えてみましょう。 特定のタイプの入力が与えられた場合に、特定の次元でサイズ1の出力行列を常に生成する場合、その事実は出力のタイプにエンコードされます（スカラー/ベクトル/コベクトルになります）。
• 改良：純粋な行列設定で行列引数を取る関数が、入力のサイズを1つ以上の次元で1にする必要がある場合、この事実が型にエンコードされていない入力の受け入れを拒否することがあります。

上記に同意する場合、ベクトルの転置は上記の種類の共ベクトルでなければなりません。anx1行列の転置は、1xn行列を生成します。 結果の最初の次元に沿ったサイズが常に1であるという事実をエンコードすると、上記のようにコベクトルが得られます。

行列代数の観点から始める場合、あなたの言うことは正しいです。 これは、MATlabがおそらく完全に実装しているモデルです。 すべてがマトリックスです。 これは閉鎖系であり、行列に対するすべての操作で新しい行列が生成されます。

この問題のポイント（ベクトルは単なる行列ではないため、ベクトルの転置を真剣に受け止める）は、その行列代数モデルから離れることであるという印象を確かに持っていました。理由により、1x1行列から数値を分離したい場合に矛盾が表示されるためです。効率の。 次に、線形代数のモデルに従うこともできます。このモデルでは、フィールド（スカラー）、ベクトル空間（およびそれに対応するデュアル）、および線形演算子/変換（行列）の空間が明確に区別されます。

Juliaの線形代数演算は、スカラーとベクトルを持ち、ユーザーを二度と推測しようとしないなどのいくつかの注目すべき例外を除いて、MATLABの伝統にかなり強く根ざしていると思います。 それから離れすぎているものは、おそらく非常に大きな混乱です。

上記の私の公理は、スカラーとベクトルを行列から分離したいときに現れる不整合を解決するために役立つはずだと私は信じています（効率と正確さの理由から）。 しかし、私は他の可能なシステムについて聞いて間違いなくオープンです。

ここで@Juthoに同意します。 この問題の全体的なポイントは、MATLABの「すべてがマトリックスである」セマンティクスから離れることです。 宇宙は、線形代数演算の下で閉じられるようにするためにMATLABの「シングルトンの寸法を末尾に追加することができます」ルールが必要であるが、そのルールの定義は、タイプのメンバーを含むクラス同値Tとタイプの他のArray{T,N}についてすべてNであり、MATLABの型システムが決定不能である主な理由です。 （ Joisha and Banerjee、2006の定理1を参照してください。結果は形状で示されていますが、問題は、配列ランクを変更するとプログラムのセマンティクスがどのように変更されるかということです。）

しかし、スカラー、ベクトル、コベクトル、および行列の乗算は連想的である必要があるということについては、まだかなり良いコンセンサスがあったと思います（ただし、2つの非スカラーが乗算してスカラーを生成する(v'*v)*vなどは例外です）。たとえば、 v'*M*vはスカラー、 M*vはベクトル、 v'*Mはコベクトルを生成する必要があります。 これらの条件を満たす一方で、すべてがマトリックスのセマンティクスからどれだけ離れることができるかはわかりません。
これ以上避けようとしていることは何ですか？代わりにどのプロパティを取得したいですか？

場合によってはTとArray{T,0}だけを混同するとしたら、どれほど悪いことでしょうか。 （例：インデックス作成： M[:,2]はArray{T,1}を生成しますが、 M[2,2]はArray{T,0}生成しません）

Transpose{Vector}を使用しても、有効なセマンティクスを維持できます。

私は結合性に関するすべてのコメントを読み直し、その議論のほとんどは実際には結合性自体に関するものではなく、内積と外積のセマンティクスに関するものであると結論付けました。 どちらにも当てはまらない表現を見つけたら、それを指摘してください。

Matlabタイプのセマンティクスの問題は、 M*v'とv*Mが機能しない場合でも機能する場合があることです。 Mがm x 1場合、 M*v'は有効であり、外積のような数量を返します（ v'は1 x n ）。 同様に、 Mが1 x mあり、「末尾のシングルトンを追加できる」ルールがある場合、 v*Mはn x 1と1 x mの積として評価できます。

TとArray{T,0}を混同する問題は、APLの文献でも提起されました。APLでは、多次元配列が再帰的にネストされているため、 Array{T,0}とTのどちらであるかという問題が発生します。 Tまで再帰する）であり、そうでない場合は「浮動配列」（ Array{T,0}のみまで再帰する）です。 More、1973は、どちらの選択も公理的に一貫していることを実際に証明したと思います。 ほとんどの開業医が引退するか、他の何かに移る前に、APLがどちらを使用するかという問題を解決したかどうかはわかりません。

@jiahao ：あなたの観察がどれほど基本的であるか私は

v[i] = e_i' * v

線形代数とインデックス付けのセマンティクスを結び付けます。 しかし、あなたはまた考慮する必要があります

M[i,j] = e_i' * M * e_j

これは、右からの基底ベクトルを持つ内積が2次元に沿ったインデックス付けに対応することを示しています。 したがって、コベクトルv'のi番目のエントリは次のようにインデックス付けする必要があると主張します。

v' * e_i = v'[1, i]

もちろん、最初のインデックスとして1以外のものを書きたいのですが、どうでしょうか。
とにかく、許可するので

e_i' * v = v[i] = v[i, 1]

その場合、上記の場合も1をプレースホルダーとして許可する必要があります。

ただし、 v' * e_iはスカラーであるため、 e_1' * (v' * e_i)はスカラーではなく、共ベクトルです。 したがって、寸法はv'[1, i] = e_1' * v' * e_iを考えると一致しません

編集：これは、インデックス作成で末尾のシングルトンを許可することに反対する議論かもしれないと思いますか？

はい、行列のインデックス付けは次の論理的なステップです。 e_i' * M * e_jは、実際には結合法則が役立つ式の1つです。

(e_i' * M) * e_j = m_i' * e_j

e_i' * (M * e_j) = e_i' * m_j

等しくなければなりません。 行列のインデックス付けは、ベクトルインデックス付けルールとコベクトルインデックス付けルールから導出できます。

この問題を一貫して解決するには、 v[i, 1]ような式を禁止する必要があると思います。これは、このインデックス作成動作を許可するルールがあるためです。
a） A*v'とv*A疑似ケースが機能するはずです（前者は機能しますが、後続のシングルトンルールを一貫して適用しないため後者は機能しません）。
b） v[i] = v[i, 1, 1, 1]の同等性を考慮すると、対応するコベクトルインデックスルールは(v')[1, 1, 1, i]ようになり、一貫性を保つために、コベクトルに対応する「任意の数の先行シングルトンを許可する」ルールが必要です。 独自に定義された一次元の欠如は非常に気がかりです。

このインデックスの推論は実際にはどこにも行かないと思います。 インデックス付けはN次元配列の一般的なプロパティであり、 N=1またはN=2単純な行列式として記述できることは、かなり些細なことであり、基本的なものは含まれていません。情報。 ただし、これは上位の配列に一般化されないため、インデックスを作成するときにコベクトルに先頭の1が必要かどうかを判断するために使用しないでください。 これは、以前の投稿で観察されたように、すぐに不整合につながります。

上で述べたように、私は1つのインデックスを追跡することに依存するのが好きではなく、それが必要であるか、または本当に役立つ単一の状況を考えることができませんでした。 しかし、私の視点はあまりにも限られていることを受け入れることができます。

私はこれらすべてを完全に消化していませんが、私の主な質問は単純です： size(covector)は(n,)または(1,n)等しいですか？

それらがAbstractArrayファミリーの一部でない場合、 sizeを定義する必要はありません。

実用的な理由から（数字などのように）定義されると思いますが、私の投票は(n,)ます。 ストレージ/コンテナの観点からは、ベクトルとコベクトルの区別はありません。 したがって、コベクターをコンテナーとして使用する必要もありません。したがって、コベクターはAbstractArray階層に属していません。 線形代数演算に関して、ベクトルとは異なる動作をすることを表現するのは、単純なラッパータイプです。

「代数と幾何学が分離されている限り、それらの進歩は遅く、それらの使用は制限されています。しかし、これらの2つの科学が統合されたとき、それらはそれぞれの相互の力を貸し、完全に向かって一緒に行進しました。」 -ジョセフ・ルイ・ラグランジュ

もっと貢献できればいいのですが、物理学者や技術者が使う洗練された数学的ツールを直感的で正確に使えるシステムが好きだと思いました。 おそらく、MITからのこのリソースは役に立つかもしれません...

http://ocw.mit.edu/resources/res-8-001-applied-geometric-algebra-spring-2009/lecture-notes-contents/

実際、考えてみると、もっと公平だと言えます

e_i' * x = x[i, :] # x is a vector or matrix
x * e_j  = x[:, j] # x is a covector or matrix

次に、マトリックスのインデックス作成では、

e_i' * M * e_j = e_i' * (M * e_j) = e_i' * M[:, j] = M[:, j][i, :] = M[i, j]
e_i' * M * e_j = (e_i' * M) * e_j = M[i, :] * e_j  = M[i, :][:, j] = M[i, j]

現在、これはJuliaには当てはまりません。たとえば、 v[i, :]現在、スカラーではなく1x1配列を生成します。 （しかし、多分それはすべきではありません）
e_i' * M * e_jでの行列乗算の結合性は、さまざまな次元M[:, j][i, :] = M[i, :][:, j]に沿ったスライスの可換性に対応します。これは、望ましい機能のようです。
上記の理由により、

v'[:,i] = conj(v[i])

@Jutho ：この「繰り返しスライスとしてのインデックス作成」パラダイムは、より高次元の配列/テンソルに一般化すると思います。各次元に1つのスライスを任意の順序でインデックスに適用します。 これは、 e_iなどに対応する1次テンソルが任意の順序である一連の収縮に対応します（どの次元が一致するかを追跡している限り）。

この「繰り返しスライスとしてのインデックス作成」パラダイムは、より高次元の配列/テンソルに一般化すると思います。各次元に1つのスライスを適用して、任意の順序でインデックスを作成します。 これは、e_iなどに対応する1次テンソルを任意の順序で使用する一連の縮約に対応します（どの次元が一致するかを追跡している限り）。

はい、私はテンソルの縮約などに非常に精通しています。実際、行列要素/テンソル要素を取得することは、標準の計算基底で期待値を取得することに対応します。つまり、いくつかの基底ベクトルで収縮します（少なくとも直交基底がある場合）。 ）が、インデックスがe_iまたはe_i'縮小に対応するかどうかに関して一意の関連付けはありません。 これは、対応するインデックスが共変または反変の位置に表示されるかどうかの決定に対応し、一意の決定はありません。 上位インデックスと下位インデックスのすべての可能な組み合わせには、有用なアプリケーションがあります。 しかし、 e_iおよびe_i'とのn x 1行列）で導入された便利なトリックであり、（共役からの正規マッピングがあるユークリッド空間にいるためにのみ機能します） ）ベクトル空間を双対空間に。

特に、上記で説明したプロパティが必要な場合は、 M[i,:]が別のオブジェクト（ 1xn行列またはコベクトル）を返し、次にM[:,i]返すようにする必要があります（ nx1行列またはベクトルである）。 これはきれいに高い次元に一般化されていないという事実は、まさにこの問題の主要な論点の一つであり、ほとんどの人はAPLのインデックス作成に賛成しているように思える、番号でインデックスさ寸法がドロップされている場合（すなわち、両方のM[:,i]とM[i,:]は、ランク1の配列、つまりベクトルを生成します。 インデックス付けは配列のプロパティであり、最初にすべての混乱/不整合を引き起こすのは、インデックス付けの動作と線形代数演算のこの混合です。 ランクN=2オブジェクトの閉じたエコシステム内にとどまる限り、一貫性を保つことができます。つまり、すべてが行列であり、ベクトルと数値であり、高次元の配列を考慮することはありません。

あなたが言うように、私はまた、 M[i,:]が上記の私の推論によって共ベクトルを生成しなければならないことに気づきました。 したがって、コベクトルを持つことは、あるレベルではAPLインデックス付けと根本的に矛盾しているようです。 APLインデックス作成を好む場合（そして私はそれが好きです）、問題は、その世界とコベクターが存在する世界との間に線を引く場所になります。 （私は2つを調整することが可能になることを望んでいました、多分あなたの残りは私達がそれをあきらめなければならないことにすでに気づいていましたか？）

あなたがそれについて考えるならば、この対立はおそらくそれほど驚くべきことではありません：

• APLインデックス作成では、意味のあるインデックス作成可能なディメンションのみが結果に保持されます。 残りは絞り出されます。
• v'それを行うとすると、 v' = conj(v)ます。 代わりに、コベクトルは欠落している最初の次元を追跡していると見なすことができます。

基本的には、乗算、加算/減算、および左除算を定義するだけで、コベクトルを可能な限り制限することから始めるのがよいと思います。

それらを<: AbstractArrayしないという考えのようです。 それらを新しいLinearOperatorタイプのサブタイプにすることは意味がありますか？ （私が知っていることは以前に議論の余地がありましたが、結論を完全に覚えていません。）

多重継承やインターフェースの言語構築（どちらも議論されています）がないため、特定の概念は「暗黙の」インターフェース、つまり定義する必要のある一連のメソッドによってのみ実装される必要があると思います。 イテレータはそのような概念の1つであり、線形演算子はおそらく、型階層ではなく一連のメソッドで指定する必要がある別の概念です。 抽象型LinearOperatorあり、そのサブ型となるMatrixがないのは奇妙なことです。

@toivohこれは重要な考慮事項です。これが、行列からi番目のベクトルまたはコベクトルを抽出するためにrow(M,i)やcol(M,i)などの新しい関数を提案した理由です。 これらの関数は、2次元配列Mと、行列代数に関心のある人向けです。 最初はMATLABスタイルのインデックス付けよりも少しわかりにくいように思われるかもしれませんが、全体として、ベクトルの概念とそのデュアル/転置/コベクトルを概念的に分離すると、物事を明確にするのに役立ちます。 量子力学の場合、ベクトルと共ベクトルのこの区別が複雑なベクトルにとって非常に重要であるという理由だけで、フィールド全体がディラックのブラケット記法にジャンプしました。ディラックの記法はこれを明らかにします。 Juliaもこれを実行し、高次元のストレージ配列と高次元の線形代数に適したツールになることを願っています。 （私たちは貪欲だからですよね？）

MATLABの経験があり、ほとんどが実際の行列に精通している人（ただし、ハードコアの線形代数の狂信者ではない）は、最初は、私たちの何人かが主張していることが重要である理由を理解していないかもしれませんが、私は信じてください。

これは前に言いましたが、繰り返します。私の観点からは、この優先順位のリストがあり、因果関係は下向きに流れています。

（1）配列は基本的に、すべてのJuliaユーザーが使用するストレージコンテナーであり、これに最適なセマンティクスが必要です。 とにかく、APLスタイルのルールは非常に良い解決策のようです。 一方、MATLABスタイルの最小2次元配列で、末尾に1次元のインデックスがある仮定は不自然で混乱しているように見えます。また、Juthoが言ったように、プログラミングがずさんなことになり、配列の次元。 これまでのところ、ベクトルv場合、 vは1次元であるため、コードv[i,:]はエラーをスローするはずです。 +や.*ような要素ごとの演算は、行列や多重線形代数だけでなく、あらゆるコンテナクラスに役立ちます。 以下のもののために人々が作る唯一の譲歩ストレージコンテナは、 .*などの余分なドットです。

（2）すべてではありませんが、ほとんどのJuliaユーザーは行列代数を使用するため、一部のベクトルおよび行列演算に構文糖衣構文を追加します。ほとんどの場合、 *記号を使用します（ただし、行列除算などがある場合があります）。 このシステムでは、1次元配列と2次元配列は、それぞれ列ベクトルと行列です。 完全に機能する行列システムの場合、行ベクトル（コベクトル）と転置演算'も必要です。 行ベクトルはあらゆる意味で1次元配列であり、そのようにインデックスを付ける必要があると断言します（そして、確かにcovec[1,i]とは異なります!!）APLルールを使用すると、いくつかを作成する必要があります。ベクトルとコベクトルの区別、および型システムはこれに理想的です（ラッパー型ではなく、1次元および2次元配列の型エイリアスとして行列とベクトルをすでに再利用できたのは幸運でした...原則として可能でしたそれらもラップしますが、要点がわかりません）。 型システムを使用すると、コンパイラはCoVector * Vectorがスカラーであり、 Vector * CoVectorが行列であると判断できます。 toivohが言ったように、_MATLABの観点から、CoVectorは「欠落している」最初の次元を正確に追跡しています。_カジュアルユーザーはこれらのオブジェクトを作成する必要はありません。 ベクトルと行列を入力し、 *と'演算を使用します。 気になる人はその違いに気づき、感謝するでしょう。 ユーザーにとっての_最大の_変更は、 M[i,:]を新しい関数row(M,i)使用するように変更するか、 Transpose(M[i,:])やM[i,:]'ようなラッパークラスに変換する必要があることです-ディラック記法のように、どのオブジェクトがベクトルで、どのオブジェクトが共ベクトルであるかを決して忘れないため、これは利点と考えることができます。タイプアサートを使用してオブジェクトに割り当てると、必要に応じてエラーが発生します。 ただし、この表記については議論する価値があると思います。 将来的には、ラッパーのシステムを拡張して、効率的な遅延評価を可能にする可能性もあります。 私が見る限り、それは誰にとってもお互いに有利です。

（3）多重線形代数に興味があり、双対空間と転置式の違いなどを学ばなければならなかった人もいます。Juthoはこれに触れています。 Juliaの配列は、すでに高次元のテンソル用の優れたストレージデバイスであり、追加のパッケージ（Baseに入る場合と見つからない場合があります）が私たちのような人々によって使用されます。 2より大きい次元の配列で定義された'や*ような操作は必要ありません。 インデックスを明示的に並べ替えても、よりクリーンに実行できない'ストレージ指向のユースケースは見当たりません。 1次元インデックスを追跡するという全体的な考え方は、概念の魅力を低下させるだけです...したがって、MATLABのように1次元および2次元配列に対してのみ'を保持してください：）（参照してください。 MATLABについて言う...）

完全に機能する行列システムの場合、行ベクトル（コベクトル）と転置演算 'も必要です。

この声明は本当に問題の核心に迫っています。 インデックス作成、転置、および*製品はすべて混合されています。 また、さらにような関数を導入することなくcovectorsのものと行ベクトルの完全なセマンティクスを調整することは不可能であるrow(A, i)返すためにiの行をA Aとして1次元配列ではなくコベクトル。 現在、 A[1, :]は、「Aの最初の行を取得する」と「Aの2番目の次元に沿って最初のスライスを取得する」の両方を意味したいと考えていますが、これらの概念は、コベクトル提案では基本的に互換性がありません。

行ベクトルは、あらゆる意味で1次元配列であり、そのようにインデックスを付ける必要があると断言します。

私はあなたがこの声明に少し気難しいと思います。 前の説明では、完全な線形代数セマンティクス（正しい積と転置を使用）が必要な場合、行ベクトルは1次元配列と同じ型を持つことはできないことを明確に確立しています。 まず、コベクトルへのインデックス付けは、内積dotとの一貫性を保つために、複素共役値(v')[1] = conj(v[1])を返す必要があります。 第二に、コベクトルはベクトルではなく、ベクトルで内積を生成するのを待っている線形汎関数です。 第3に、ベクトルと共ベクトルは、 hcatとvcat下で異なる配列連結動作をします。 これらすべての理由から、行ベクトルを「あらゆる意味で1次元配列」にすることはできません。

末尾のシングルトンを取り除くことに賛成です。それを利用したJuliaコードを見たことがないと思います。 もともとは0次元配列に必要だと言っていましたが、 X[]は問題なく機能することがわかりました。

行ベクトルのrow(M,i)関数とともに、APLインデックス作成が最も理にかなっており、適切な妥協点のように思われます。 行ベクトルのインデックス付けについてはよくわかりませんが、 (v')[1,i]は好きではありません。

まだ触れていないもう1つの大きな決定は、タイプです。 以前にこれを試してみた私の1つの発見は、 v' AbstractVectorにするのは非常に難しいということです。

2つの可能なオプション：

1. 行列とベクトルに別々のタイプを使用します。
   
   
   
   • Transpose <: AbstractMatrix
   
   
   • CoVector <: Any
   
   
   • Factorizationオブジェクトのある種の転置。
   
   
2. すべての転置に同じタイプを使用しますが、 X'はAbstractMatrixません
   
   
   
   • Transpose <: Any
   
   

接合については、次のいずれかを行うことができます

a。 ConjugateTranspose定義します（上記のオプション1を使用する場合はConjugateCoVectorとともに）

b。 Conjugateラッパータイプを使用し、適切にネストします。 Transpose{Conjugate{T}}とConjugate{Transpose{T}}どちらを使用するかについて、何らかの規則が必要になります。

AbstractMatrixサブタイプではなくTranspose{Matrix}を持つのが好きです。 私たちがベースに持っている最も近い類似物は、 Symmetricような特別な行列タイプであると思います。これは、代数的に行列のように動作しますが、インデックス付けのセマンティクスでは動作しません。 （＃987は、複数の固有性または神聖な特性がない場合、型階層は代数的セマンティクスよりもコンテナーセマンティクスを尊重する必要があることを確立しました。）

基本的に「セマンティックタグ」である型を構成する問題は、＃8240にも現れました。 活用は要素の基礎となる分野にまで及ぶ概念であるため、 Transpose{Conjugate{T}}が望ましいと思います。

以下は、MATLABと同じ末尾のシングルトンルールに従う場合と従わない場合の例です。

• インデックス付け操作では、末尾のシングルトンが許可されます。 （MATLABのように）

julia> (1:5)[5,1,1,1,1,1,1]
5

• インデックス作成操作では、末尾のスライスは許可されていません。 （MATLABとは異なり、MATLABはそれらを許可します。）

julia> (1:5)[5,:]
ERROR: BoundsError()
 in getindex at abstractarray.jl:451

• ランク> = 3の配列の場合、配列のランクよりもインデックスが少なく、最後のインデックスがスカラー（MATLABなど）の場合、暗黙的な末尾のシングルトンがインデックス付き代入演算に追加されます。

julia> A=zeros(2,2,2); A[1,2]=5; A #Same as A[1,2,1]=5
2x2x2 Array{Float64,3}:
[:, :, 1] =
 0.0  5.0
 0.0  0.0

[:, :, 2] =
 0.0  0.0
 0.0  0.0

• ランク> = 3の配列の場合、配列のランクよりもインデックスが少なく、最後のインデックスがスカラーではない場合（MATLABのように）、暗黙の末尾の_slices_がインデックス付き代入演算に追加されます。

julia> A[:,:]=3; A
2x2x2 Array{Float64,3}:
[:, :, 1] =
 3.0  3.0
 3.0  3.0

[:, :, 2] =
 3.0  3.0
 3.0  3.0

• ランク> = 3の配列の場合、配列のランクよりもインデックスが少なく、最後のインデックスがスカラー（MATLABなど）の場合、暗黙的な末尾のシングルトンがインデックス操作に追加されます。

julia> A=reshape(1:8,2,2,2); A[:,1]
2-element Array{Int64,1}:
 1
 2

julia> A[:,1,1]
2-element Array{Int64,1}:
 1
 2

• ランクr> = 3の配列の場合、配列のランクよりもk <rのインデックスがあり、最後のインデックスがスライスである場合のインデックス作成操作は、残りのランクrk配列を暗黙的に線形化します。 （MATLABのように）：

julia> A=reshape(1:8,2,2,2); A[1,:]
1x4 Array{Int64,2}:
 1  3  5  7

julia> A=reshape(1:8,2,2,2); A[1,:,:]
1x2x2 Array{Int64,3}:
[:, :, 1] =
 1  3

[:, :, 2] =
 5  7

• 末尾のシングルトンは、割り当て操作では削除されません。 （MATLABとは異なり）

julia> A=zeros(1); A[1] = randn(1,1)
ERROR: `convert` has no method matching convert(::Type{Float64}, ::Array{Float64,2})

You might have used a 2d row vector where a 1d column vector was required.
Note the difference between 1d column vector [1,2,3] and 2d row vector [1 2 3].
You can convert to a column vector with the vec() function.
 in setindex! at array.jl:307

julia> A=zeros(1,1); A[1,1] = randn(1)
ERROR: `convert` has no method matching convert(::Type{Float64}, ::Array{Float64,1})
 in setindex! at array.jl:308

• Juliaは、有効な操作を許可するときに、末尾のシングルトンディメンションを自動的に追加しません。 （Matlabとは異なり）

julia> 1/[1.0,] #In MATLAB, interpreted as the inverse of a 1x1 matrix
ERROR: `/` has no method matching /(::Int64, ::Array{Float64,1})

• 外積は機能し、前のルールの例外です。 それらのセマンティクスは、最初の引数で末尾のシングルトンを暗黙的に使用します。 （Matlabのように）

julia> [1:5]*[1:5]' # Shapes are (5,) and (1,5) - promoting to (5,1) x (1,5) works
5x5 Array{Int64,2}:
 1   2   3   4   5
 2   4   6   8  10
 3   6   9  12  15
 4   8  12  16  20
 5  10  15  20  25

これらの動作をどのようにしたいかを結論付けたら、これらのことは少しクリーンアップする価値があるようです。 最後のインデックスがスライスであるインデックスが少なすぎる場合の現在の動作は、特に怪しいようです。

ワオ。 Jiahaoが提示した例は、非常に厄介です...暗黙性とあいまいさのために、インデックス作成操作とインデックス付け割り当て操作でシングルトンを追跡するのは好きではありません。 これらの動作を事前に認識していない場合、実際に別のことを行おうとしているときに、あることを実行してしまう可能性があります。 私は、言語の正確で明確な使用法にコミットし、あいまいなショートカットを回避することに賛成です。

これを実際に実装するには、ある種の三角形のディスパッチが必要になります。そうしないと、「 Complex64またはComplex128エントリを持つ行列、その転置」などをどのように表現するかわかりません。 、またはその共役転置」。 特に上記のオプション2 + bを使用する場合。

@ esd100 、これらの

行ベクトルは、あらゆる意味で1次元配列であり、そのようにインデックスを付ける必要があると断言します。

私はあなたがこの声明に少し気難しいと思います。

本当です！ 申し訳ありませんが@jiahao 、私は[]インデックス作成の動作を厳密に参照していました。 連結が重要な考慮事項であることは正しいです。それを行う（行列を作成する）自然な方法は（この場合は1 xnサイズと考えることで）かなり明白だと思います。 明らかに、コベクトルは「あらゆる意味で」1D JuliaArrayではありません...それが全体のポイントです...

ジアハオの例も私を悩ませています。 私は、可能性のある後続のシングルトンの動作を削除することに賛成です。 後の次元を線形化することは有用かもしれませんが、配列の次元数を忘れるような怠惰を助長する可能性もあります...（これは「あいまい」と「危険」によって暗示されるものだと思います...私は本当に欲しいですたとえば、16次元配列を15次元配列のように扱うと、Juliaがエラーをスローします。

これらのどれが曖昧または危険ですか？

4つ目は、あいまいで危険なようです。

julia> A=zeros(2,2,2); A[:,:]=3; A
2x2x2 Array{Float64,3}:
[:, :, 1] =
 3.0  3.0
 3.0  3.0

[:, :, 2] =
 3.0  3.0
 3.0  3.0

明らかに（私にとって）これは構文エラーであるはずです。 Aはランク3であり、3次元はまったく参照されていません。 3番目の次元がエラーによって省略された可能性が高く、見つけにくいバグがコードに導入されています。 彼の時点でエラーが発生したことを感謝します（IDLとFortranの両方にあるため）。

配列が正しいインデックス数でのインデックス作成のみを許可するか、1D線形インデックス作成の特殊なケース（非常に便利なため）を許可するのが最善だと思います。 これには、後続のシングルトンを禁止することも含まれます。

または1D線形インデックスの特殊なケース（非常に便利なため）

私たちの原則はどれほど簡単に売られますか？ :)

私は線形インデックスがそれほど好きではありませんでした。 それはちょっとしたハックとして私を襲います。 多くの場合、配列を反復処理するための最速の方法が必要です。 また、単純な高密度配列を除くすべての場合、線形インデックス作成は非常に遅くなる可能性があります。 とはいえ、線形インデックスを完全に排除することはできないかもしれません（パフォーマンス上の理由と、コードの破損が多すぎるため）。

はい、十分に真実です。 しかし、少なくとも1Dインデックスは視覚的に区別されます。 一方、6D配列に5Dでインデックスを付けることは、それほどではありません。 いずれにせよ、私は他の方向に進むよりも、より厳密なインデックス作成ルールを持ち、1D線形インデックス作成をあきらめたいと思います。 特に、メモリを共有する配列への再形成された参照を簡単に取得できるためです。

線形インデックス作成に{}角かっこ（またはその他）を使用し、多次元インデックス作成に[]を保持できますか？ ただのアイデア...

2015年3月23日には、14:36で、ボブPortmannの[email protected]は書きました：

はい、十分に真実です。 しかし、少なくとも1Dインデックスは視覚的に区別されます。 一方、6D配列に5Dでインデックスを付けることは、それほどではありません。 いずれにせよ、私は他の方向に進むよりも、より厳密なインデックス作成ルールを持ち、1D線形インデックス作成をあきらめたいと思います。 特に、メモリを共有する配列への再形成された参照を簡単に取得できるためです。

—
このメールに直接返信するか、GitHub https://github.com/JuliaLang/julia/issues/4774#issuecomment-84805310で表示して

また、構文を分離できたらいいのにと思います
通常のインデックス構文からの線形インデックスの場合ですが、私はそれに同意します
非常に大きな変化かもしれません。

この問題は多くの議論を呼んでいるように見えますが、インデックス作成を改善するための実際の作業のほとんどは、0.4サイクル全体で非常に多くのプルリクエストで発生しています。 たとえば、 CartesianIndexと友達ができたので、線形インデックスとデカルトインデックスの構文を分離する必要がある理由がわかりません---実際、それらを組み合わせることができます（＃10524）。 線形インデックスも削除したいのですが、パフォーマンスが向上する場合があります（おそらく、主に＃9080が原因です。 enumerateとzipは同じ問題に悩まされています）。 おそらく、＃10507のように、 eachindexラッパーとしてfastindexを実装する必要があります。

ルールのインデックス作成に興味がある場合は、この問題を打ち負かすのではなく、最も興味深いフロンティアに焦点を当てましょう。 現時点では、それは間違いなく＃10525です。 特にhttps://github.com/JuliaLang/julia/pull/10525#issuecomment-84597488には何らかの解決策が必要です。

@timholy高速デカルトインデックス作成のすべての開発を実際に追跡したわけではなく、base /

いくつかの点で、知ることはあまりありません。内部ではかなりの量が行われていますが、アイデアはそれを簡単に使用できるようにすることです。 とても文字通り

k = 0
for I in eachindex(A)
     B[k+=1] = A[I]   # B is being linearly-indexed, A is being cartesian-indexed
end

あなたが知る必要があるのはそれだけかもしれません。 （言い換えれば、 eachindexのヘルプが必要なすべてのドキュメントである可能性があります。）ただし、この基本的なパラダイムのいくつかの拡張を使用して、非常に多くのアルゴリズムを記述できることがわかります。 それらの拡張機能が何であるか、そしてなぜそれらが強力であるかは、実際、あまり明白ではないかもしれません。

私はこれを今後数ヶ月のうちに書き留める予定ですが、人々が本当に詳細を知りたいのであれば、おそらくJuliaConの話は合理的でしょう。 @Juthoまたは@mbaumanは、私と同じようにその話をすることができます。

あいまいさについてさらに追加しますが、最後の議論のいくつかは特定の重要なポイントを要約したと思います。 おそらく私は、部外者として、または恐れから、この種の曖昧さに敏感であり、劇的に聞こえるリスクがあります。 私の謙虚な意見では、単純でミッションクリティカルな思考演習がいくつあっても、単純なエラーの費用便益分析が価値のない道にあなたを導く可能性があります。

＃10507のように、各インデックスのラッパーとしてfastindexを実装する必要があります。

@timholy eachindexが高速線形配列のUnitRangeを返さない理由はありますか？ それでもタイプは安定しており、呼び出し元がCartesianIndexを確実に取得したい場合は、手動でCartesianRangeを作成できます（ CartesianRangeはエクスポートされないため、 eachindex(size(A))メソッドを追加することもできます）。

それが最初にやったことですが、 @ Juthoがそれを変えたと思います。 （それが当てはまらない場合は、おそらく気付かずに変更しました。）変更は一貫性のために動機付けられたと思います（したがって、 CartesianIndexを取得することを期待できます）。これにはある程度の意味があります。 。 しかし、あなたが指摘するように、これを確実にするための代替手段があります。

@Jutho 、何か考えはありますか？

eachindex変更したことを覚えていませんが、変更できた可能性があります。 配列のタイプに関係なく一貫した結果が得られることを除いて、私は確かにそれの正当な理由を覚えていません。 しかし、効率的な線形インデックスを使用する配列と使用しない配列の違いがドキュメントで明確に説明されている場合、効率的な線形インデックスを使用する配列の場合、 eachindexが線形範囲を返すことができなかった理由はわかりません。

@timholy 、あなたの以前の投稿に応えて、私はJuliaConに参加できないので、 CartesianIndexことについて気軽に話してください（とにかく私はいくつかの最後の仕上げを提供しただけです）。 すでにカンファレンスのレポートとビデオを楽しみにしています。

気まぐれな考え：任意の次元（次元> 2を含む）の配列Aの場合、 A'がAインデックスを周期的に並べ替えることができます。 したがって、 A'[i, j, k] == A[j, k, i] 。 これは、MATLABのように解釈された場合（つまり、それぞれ[n、1]および[1、n] 2d配列）、2d配列の通常の行列転置、および行と列の「ベクトル」の通常の転置になります。 したがって、2D列の「ベクトル」を真のコベクトルにマップしたり、2D行の「ベクトル」を真のベクトルにマップしたりすることはありません。 （このプロパティは良いと思いますが、他の人は同意しないかもしれません。）配列オブジェクトとして解釈される行列とベクトルのアイデンティティA'' == A'とv'' == vを与えます。 上で説明したようなタイプ階層（真のベクトルと共ベクトルが抽象配列と十分に区別されている）を考えると、 'は、線形代数の概念に対応する真のベクトルと共ベクトルに対してまったく異なる方法を与えることができます。 v'' == v満たす必要はありません（ただし、それが人々が望むと判断した場合は可能です）。

明確にするために：私は'が次元> 2の配列のためのメソッドを持っている必要があると一瞬考えませんが、私は上記のこの提案を見ていませんでした（それが「インデックスを逆にする」という意味でない限り） "）そして私はそれについて言及したいと思いました。 私がそれがしているのを見る最も害（一応の）は概念的です:(少し恣意的な）組み合わせ演算を線形代数の領域として通常取られる演算子と混同します。 これに対して、線形代数の概念を純粋にデータ中心の概念に拡張しようとすると、少なくともある程度のそのような混乱は避けられないと答えることができます（この議論全体で証明されています）。 そのため、多次元配列の巡回置換の便利な省略形を、多次元配列の次元に対して一般的に'が何をすべきかを決定する副産物として、期待されるケースに還元される限り、刈り取ることができます。 2次元。 A'(k)[I]がA[I]のインデックスをk回周期的に並べ替え、 A'(ndims(A))[I] == A[I]とA'(-k)[I]がインデックスを並べ替えるように、整数引数を取るメソッドを追加することもできます。反対方向に。

ちょっとした考え。

transposeが多次元配列に対して定義されている場合、それでもA''=A満たすことをお勧めします。つまり、それ自体が逆です。 これは、以前の提案と直接矛盾しています。

それは公正です。 私が言ったように、私の提案は、転置の線形代数的重要性と、d> 2の場合に課す配列中心の重要性との間に亀裂を生じさせることに抵抗がない場合にのみ（潜在的に）魅力的です。 私の推論は、その裂け目がすでに（一種の）起こっている限り、そしてメソッドが他の方法で完全に使用されないのであれば、インデックスを並べ替えるための省略形を持っているのはいいかもしれません-それが何も必要としない限りd = 2ケースを機能させるための特別な処理。 あなた（@Jutho）が述べたように、2次元の場合の転置次元が線形代数的重要性を持っていることは便利な偶然の一致です（そして、（共）ベクトルを2次元配列として識別した後でのみ）、 d> 2の場合、 transposeの数学的特性（たとえば、 A'' == Aが必要）について慎重に考える必要はありません。このルートを使用したい場合は、役立つ可能性のある方法がたくさんあります。割り当てられます。例： A' 1回周期的に並べ替え、 A'(k) k回周期的に並べ替え、 A'(I)はI::Array{Int, 1} 、長さ<= ndims(A)周期的に並べ替えますIにリストされているインデックスを並べ替え、 p::Permutationの長さ<= ndims(A) A'(p)は、 pに従ってインデックスを並べ替えます。 しかし、おそらく最善の方法は、パッケージを作成して、それが十分に役立つかどうかを確認することだと思います。

たとえば、2014年10月16日のStefanKarpinskiと2015年3月22日のsimonbyrneによって言及された2つの変更/説明をサポートしますが、1つの規定があります。

1. transposeは、一般的なテンソルではなく、ベクトルと2次元行列にのみ使用する必要があります。
2. 演算子*およびtransposeは、計算の最後に末尾のシングルトン次元を削除する必要があります。 そうしないと、末尾のシングルトン寸法が保持される場合があります。

これらの2つの変更は、多くの便利さを提供し、従来の線形代数作業内の多くのあいまいさを解決します。 彼らは、個別に考えることができる一般的な配列の索引付けやテンソル代数について意図的に何も述べていません。 （特に、テンソル転置は、行列/ベクトル転置とは完全に別個の操作であると見なす必要があります。）

この提案では、行列の乗算と転置を使用する場合、ベクトルと1列の行列の間に本質的に区別はなく、スカラー、長さ1のベクトル、および1行列の間に意味のある区別もありません。 -1行列。 ただし、 x'は、ベクトルではなく1行n列の行列になります。

一方、データを保持する目的で、任意のサイズの配列を作成できます。 乗算と転置の線形代数の概念が含まれないため、シングルトン次元は削除されません。

以下は、提案された変更を伴うJuliaセッションの架空のトランスクリプトです。

まず、スカラー、2つのベクトル、および行列を定義します。

julia> alpha = 2.0
2.0

julia> x = [1.0; 2.0; 3.0]
3-element Array{Float64,1}:
 1.0
 2.0
 3.0

julia> y = [4.0; 5.0; 6.0]
3-element Array{Float64,1}:
 4.0
 5.0
 6.0

julia> A = [1.0 2.0 3.0; 4.0 5.0 6.0; 7.0 8.0 9.0]
3x3 Array{Float64,2}:
 1.0  2.0  3.0
 4.0  5.0  6.0
 7.0  8.0  9.0

スカラーベクトルの乗算は、無関係な次元が存在する場合でも機能し、結果は常にベクトルになります。

julia> alpha*x
3-element Array{Float64,1}:
 2.0
 4.0
 6.0

julia> alpha*x[:,[1]]
3-element Array{Float64,1}:
 2.0
 4.0
 6.0

転置は対合です。

julia> x'
1x3 Array{Float64,2}:
 1.0  2.0  3.0

julia> x''
3-element Array{Float64,1}:
 1.0
 2.0
 3.0

julia> x==x''
true

julia> x'''
1x3 Array{Float64,2}:
 1.0  2.0  3.0

行列に1列の行列を掛けると、行列とベクトルの積と同じ結果が得られます。

julia> A*x
3-element Array{Float64,1}:
 14.0
 32.0
 50.0

julia> A*x[:,[1]]
3-element Array{Float64,1}:
 14.0
 32.0
 50.0

1行の行列に行列を掛けたものが1行の行列に等しくなります。

julia> x'*A
1x3 Array{Float64,2}:
 30.0  36.0  42.0

内積はスカラーであり、行列-ベクトルおよび行列-行列積のより一般的な規則によって生成されます。

julia> x'*y
32.0

julia> x'*y[:,[1]]
32.0

外積は特別なものではありません。

julia> x*y'
3x3 Array{Float64,2}:
  4.0   5.0   6.0
  8.0  10.0  12.0
 12.0  15.0  18.0

julia> x[:,[1]]*y'
3x3 Array{Float64,2}:
  4.0   5.0   6.0
  8.0  10.0  12.0
 12.0  15.0  18.0

ベクトルとベクトルの積はエラーです。

julia> x*y
ERROR: `*` has no method matching *(::Array{Float64,1}, ::Array{Float64,1})

ベクトルと行列の積はエラーです。

julia> x*A
ERROR: DimensionMismatch("*")
 in gemm_wrapper! at linalg/matmul.jl:270
 in * at linalg/matmul.jl:74

行列の乗算は結合法則です。

julia> (x*x')*y
3-element Array{Float64,1}:
 32.0
 64.0
 96.0

julia> x'*y
32.0

julia> x*(x'*y)
3-element Array{Float64,1}:
 32.0
 64.0
 96.0

julia> norm((x*x')*y-x*(x'*y))
0.0

編集：製品の内寸の降格を含む2つの例を削除しました。 彼らは現在の議論とはあまり関係がありませんでした。

末尾のシングルトン次元を破棄することは型安定操作ではないため、これにより、関連する操作の型安定性が失われるのではないかと心配しています。

私の見方では、コベクタービジネス全体は、削除されるタイプに基づいて既知のシングルトン次元を持つことです。 また、たまたま1つの列しか持たないベクトルと行列の区別を維持するためにかなりの努力をx''てきましたが、この提案により、

異端的な提案：型パラメーターから次元を削除し、実行時にすべての次元/サイズをチェックした場合はどうなりますか？ （とにかく、かなりの量を実行することになります。）そして、サイズを型パラメーターとしてエンコードする型の次元パラメーターはそのままにしておきます。 （アヒル、2週間隠れて、githubアカウントを@SomeoneWhoCertainlyIsntTimHolyUhUhNoWayに変更します。）

（もちろん、＃10525だけで本当に文句を言うでしょう。）

FWIW、それはそれほどクレイジーなアイデアではないと思います。たとえば、トーチの仕組みです。トーチの開発者は、型システム内でのジュリアの次元のエンコードに不満を表明しています。

@timholy質問：これを使用して、線形代数とベクトルの転置に関するセマンティクスを改善できますか？

それでもCoVector / DualVector / TransposeVector使用に興味がある場合は、新しいTimHolyArray{DataType}ラップする必要があり、どちらかを理解する必要があります。 2つ（または1つ）より大きい次元の配列の転置、またはtharray次元が2つ（または1つ）より大きい場合の構築TransposeVector(tharray)禁止する...実際には、あらゆる種類の実行時レベルで、現在コンパイル時エラーであるエラーを発生させる必要があります（現在定義されていないため、型システムで禁止されている乗算など）。

一方、この新しいクラス内に転置フラグを実装するのは悪いかもしれません...それは効率的で軽量なコンテナであるべきものをより複雑にします。 私はそのオプションを除外する傾向があり、コンパイラ/型システムにハードワークを任せます。

私は必ずしもあなたの考えに反対しているわけではありませんが、ベクトル転置と並行して実行できる追加の問題のようです。

@timholy ：これが進むべき道かどうかは本当に確信しています。 ディメンションにディスパッチすることが非常に役立つ場合があります。

これをすべてのアレイに適用することを提案しました。 しかし、私は今、私自身の提案に反対しています。なぜなら、多くの多次元の場合、 N次元配列に対してNループを生成する必要があるからです。 Nが型パラメーターでなければ、これ以上それを行うことはできません。

はい、これはデカルトマクロ（または私がまだ慣れていない段階的な関数:-)）の要点ではありませんか？
テンプレートパラメータとしてディメンションを使用するのが非常に面倒なC ++でも同様のことを行いました。 しかし、さまざまな配列の次元を特殊化するために大きなifステートメントが必要だったため、動的バリアントが制限されている状況がありました。

提案：

1. 現在の行列乗算動作の名前をtimesfastし、現在の転置動作の名前をtransposefastます。
2. (*)とtransposeを変更して、前のコメントのように末尾のシングルトン次元を切り捨てます。 たとえば、 u'*vはスカラーになり、 v''はベクトルになり、 (v*v')/(v'*v)が定義されます。

既存の動作はタイプ安定です。 提案された動作は、多くの線形代数テキストの規則に従います。 それらは両方とも価値があります。 おそらくジュリアは両方を持っている必要があります。

教室でJuliaを使用したいので、効率よりも利便性を重視するデフォルトの動作に投票します。

この非常に長いスレッドについて私を理解させてくれた何人かの貢献者に感謝します！

@briansutton ：あなたは本当にあなたが求めているものを再考するべきだと思います。 掛け算の意味を再定義することを提案する前に、ジュリアがどのように機能するかをより深く理解するまで待つことをお勧めします。

この問題は、可能な限り多くの特殊なケースを回避する方法に関するものです。

シングルトン次元の混乱を許可するルールは、シングルトン次元の1つが実際に気になる瞬間に崩壊します。 「[すべての]末尾のシングルトン次元を切り捨てる」ルールでは、 vが1要素のベクトルの場合、 v'はスカラーであるため、 v''もスカラー。 したがって、この提案でも、 v == v''が常に保持するとは限りません。

ルールを変更して、「配列の次元が2の場合、最後の末尾のシングルトン次元のみを切り捨てる」ことができます。 ただし、この変更されたルールを使用しても、外積v * w'は行列乗算の定義に自動的には従わず、代わりにVector * Matrix独自の特殊な定義である必要があり、定義は「形状が（N）x（1、M）でない限り、エラーをスローします」。

@jiahao ：

ベクトルと行列を使用して線形代数を実行する場合、スカラー、1要素ベクトル、および1行1列の行列を区別したくありません。 現在、さまざまな操作で3つのオブジェクトのいずれかが生成されます。 私の提案は、行列の乗算と転置の操作について、3つのうちの1つを優先表現として選択することです。

最初の例（ v==v'' ）に関しては、そもそもv要素のベクトル

2番目の例に関しては、はい、 v*w'はあなたが説明したとおりに処理する必要があると思います。 行列の乗算と転置を使用する場合、ベクトルvとN行1列の行列v[:,[1]]は、内部表現が異なっていても、同じ数学的オブジェクトを表すようにします。 これには、Nベクトル×1行M列の行列を処理するための特別なコードが必要になります。

型の安定性が重要であるとあなたはまだ確信し

@briansutton ：現在の型システムでJuliaコードを実行できるのと同じ速さで提案を実行するために必要な機構を実装してみると、非常に有益だと思います。 私は、予測可能なパフォーマンスとCメモリレイアウトの互換性を提供するというジュリアンの目標を考えると、あなたが述べた目標は達成できないと信じています。

議論が行き交うことを理解しているかどうかはわかりませんが、1つのことが私の目に留まりました。 希望的観測かもしれませんが、コンピューターが人間の脳と同じくらい速く考えることができればいいのですが。 私が言いたいのは、ブライアン・サットンが「好ましい表現を選ぶ」というプログラムについて話すとき、私たちが数学をするときと同じように考えることができるプログラムを想像するということです。 おそらく、それは今日の技術では実現不可能であり、物事を遅くしすぎるでしょう。 しかし、それはいいことではないでしょうか...

私は物理学者であり、ジュリアのアクティブユーザーです。

私はもはや、天候を維持したり、後続のシングルトンの次元をすべて削除したりすることを強く好みません。

しかし、ここで私は密接に関連した問題を提起したいと思います。

現在のJuliaの実装：

Vを3次元ランク1テンソル（ベクトル）とします。
V [1]は、1次元のランク1テンソルではなくスケーラーを提供します

Aを3x4x5ランク3テンソルとします
B = A [1、：、：]は、1x4x5ランク3のテンソルを与えます。

上記の2つの動作は完全に一貫していません。

私は次のインデックス作成/スライド機能を強く好みます。

Aを3x4x5ランク3テンソルとします
B = A [1、：、：]は、4x5のランク2テンソルを与えます。
C = A [1：1、：、：]は、1x4x5のランク2テンソルを与えます。
（現在、上記の2つは同じ結果をもたらします）

Vをランク1テンソルとします
B = V [1]は私たちにスケーラーを与えます
C = V [1：1]は、1次元のランク1テンソルを与えます。

この機能は、テンソルの形状をより簡単に変更するのに役立ち、後続のシングルトンインデックスを許可するときに役立ちます。

ベスト

Xiao-Gang

差出人：esd100 [[email protected]]
送信：2015年6月9日火曜日21:46
宛先：JuliaLang / julia
Cc：シャオガンウェン
件名：Re：[julia]ベクトル転置を真剣に受け止める（＃4774）

議論が行き交うことを理解しているかどうかはわかりませんが、1つのことが私の目に留まりました。 希望的観測かもしれませんが、コンピューターが人間の脳と同じくらい速く考えることができればいいのですが。 私が言いたいのは、ブライアン・サットンが「好ましい表現を選ぶ」というプログラムについて話すとき、私たちが数学をするときと同じように考えることができるプログラムを想像するということです。 おそらく、それは今日の技術では実現不可能であり、物事を遅くしすぎるでしょう。 しかし、それはいいことではないでしょうか...

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/4774#issuecomment-110554622で表示してください。

つまり、C = A [1：1、：、：]は1x4x5のランク3テンソルを与えます。

Xiao-Gang

差出人：Xiao-Gang Wen [[email protected]]
送信日：2015年6月22日月曜日12:01 PM
宛先：JuliaLang / julia; JuliaLang / julia
Cc：シャオガンウェン
件名：RE：[ジュリア]ベクトル転置を真剣に受け止める（＃4774）

私は物理学者であり、ジュリアのアクティブユーザーです。

私はもはや、天候を維持したり、後続のシングルトンの次元をすべて削除したりすることを強く好みません。

しかし、ここで私は密接に関連した問題を提起したいと思います。

現在のJuliaの実装：

Vを3次元ランク1テンソル（ベクトル）とします。
V [1]は、1次元のランク1テンソルではなくスケーラーを提供します

Aを3x4x5ランク3テンソルとします
B = A [1、：、：]は、1x4x5ランク3のテンソルを与えます。

上記の2つの動作は完全に一貫していません。

私は次のインデックス作成/スライド機能を強く好みます。

Aを3x4x5ランク3テンソルとします
B = A [1、：、：]は、4x5のランク2テンソルを与えます。
C = A [1：1、：、：]は、1x4x5のランク2テンソルを与えます。
（現在、上記の2つは同じ結果をもたらします）

Vをランク1テンソルとします
B = V [1]は私たちにスケーラーを与えます
C = V [1：1]は、1次元のランク1テンソルを与えます。

この機能は、テンソルの形状をより簡単に変更するのに役立ち、後続のシングルトンインデックスを許可するときに役立ちます。

ベスト

Xiao-Gang

差出人：esd100 [[email protected]]
送信：2015年6月9日火曜日21:46
宛先：JuliaLang / julia
Cc：シャオガンウェン
件名：Re：[julia]ベクトル転置を真剣に受け止める（＃4774）

議論が行き交うことを理解しているかどうかはわかりませんが、1つのことが私の目に留まりました。 希望的観測かもしれませんが、コンピューターが人間の脳と同じくらい速く考えることができればいいのですが。 私が言いたいのは、ブライアン・サットンが「好ましい表現を選ぶ」というプログラムについて話すとき、私たちが数学をするときと同じように考えることができるプログラムを想像するということです。 おそらく、それは今日の技術では実現不可能であり、物事を遅くしすぎるでしょう。 しかし、それはいいことではないでしょうか...

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/4774#issuecomment-110554622で表示してください。

あなたが求めているのは、 slice現在どのように機能しているかです。 私の感覚では、 A[stuff]はslice(A, stuff)同義語になるので、おそらくあなたはあなたの望みを得るでしょう。

親愛なるティム：

ヒントありがとうございます。 スライスしてみました。 それは私のニーズに合いません。 スライスは、:: Arrayデータ型を使用する他のコードでは使用できない新しいデータ型「subarray」を生成します。

「サブアレイ」データ型を許可するように、他のコードを変更できるかもしれません。

Xiao-Gang

差出人：Tim Holy [[email protected]]
送信日：2015年6月22日月曜日17:32
宛先：JuliaLang / julia
Cc：シャオガンウェン
件名：Re：[julia]ベクトル転置を真剣に受け止める（＃4774）

あなたが求めているのは、スライスが現在どのように機能するかです。 私の感覚では、A [stuff]はslice（A、stuff）の同義語になるので、おそらくあなたはあなたの望みを得るでしょう。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/4774#issuecomment-114268796で表示してください。

コードでAbstractArray代わりに具体的なArrayタイプを使用することに本当に依存しているものはありますか？ 物事を機能させるには、 ArrayをAbstractArrayに検索/置換するだけで済みます。

親愛なるスコット

ヒントありがとうございます。

Xiao-Gang

差出人：スコットP.ジョーンズ[[email protected]]
送信日：2015年6月25日木曜日9:55 AM
宛先：JuliaLang / julia
Cc：シャオガンウェン
件名：Re：[julia]ベクトル転置を真剣に受け止める（＃4774）

コードでAbstractArrayの代わりに具象配列型を使用することに本当に依存しているものはありますか？ 物事を機能させるには、配列をAbstractArrayで検索/置換するだけで済みます。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/4774#issuecomment-115265047で表示してください。

それはあなたのためにトリックをしましたか？ 喜んでお手伝いさせていただきます！

@wenxgwen 、または、 copy(slice(A,...))を呼び出して、既存の関数でネイティブに機能する新しいArrayのスライスのコピーを取得することもできます。

この問題を修正することは、今や儲かる努力になっています

この問題を修正することは、3つのコンマへのパスで重要になりました...

しかし、すべての深刻さで。 私は議論を完全に読み通そうとしましたが、これが以前に提案されていないことを保証することはできません：

AbstractArray定義を拡張して、基になるデータが行ベースまたは列ベースのストレージであるかどうかを定義する追加の特性（LinearIndexingと同様）を持たせることはできますか？ この追加により、次のプロパティが開きます（名前に焦点を当てないでください...概念のみ）。

v --> length-2 Vector{Col}
  [ 1
    2 ]

v'  --> length-2 Vector{Row}
  [ 1 2 ]

m --> 2x2 Matrix{Col}
  [ 1 3 
    2 4 ]

m' --> 2x2 Matrix{Row}
  [ 1 2 
    3 4 ]

Some operations:
v'  --> length-2 Vector{Col}
v'' == v
v*v or v'*v'  --> either error, or do element-wise multiplication
v' * v --> scalar
v * v' --> 2x2 Matrix  (could be Row or Col??)
v' * m --> 2-length Vector{Row}
v * m --> either error or broadcasting operation
m * v --> either error or broadcasting operation
m * v' --> 2-length Vector{Col}

Indexing:
v[2] --> 2
v[1,2] --> error
v'[1,2] --> 2
m[1,2]  --> 3
m'[1,2]  --> 2

Size:
length(v)  --> 2
length(v')  --> 2
size(v)  --> (2,)
size(v')  --> (2,)
length(m)  --> 4
size(m)  --> (2,2)

明らかに、この提案には多くの定義が欠けていますが、おそらくそれは議論を始めることができます。 列インデックスと行インデックスの両方のストレージを同時にサポートし、途中でいくつかの問題を「修正」することはできますか？

ループや他の多くの操作について私が考えるのは当然のことなので、Juliaが行ベースのストレージであることを強く望んでいます。 （そして私だけがこのように考えているとは思いません）コメントをお願いします！

コンストラクターにも行または列を取り込むことは興味深い考えです。 これは、GitHubの発行システムのどこかで以前に議論されたと思います。 私は間違っている可能性があります！

私の教科書のほとんどは数学に列を使用しているため、個人的には列ベースのストレージを好みます。ジュリアでは、代わりに行を使用するようにすべてを変更する必要はありません。 私も最初は奇妙だと思いましたが、すぐに私の仕事では問題になりませんでした。 行で簡単に表現できるアルゴリズムがありますが、これが必要なときに非標準のストレージを使用できるようにする必要があるのはこのためです。 関数を呼び出すときにどのタイプを使用するかについて疑問が生じないように、エクスポートされる関数がある場合は、常に列の主行列または列ベクトルを返すという規則があることを願っています。 そうしないと、非常に面倒になり、返されるタイプを常に調べなければならないときに使用するのが不快になる可能性があります。

列ベースと行ベースは、この問題の範囲内ではありません。

@tbreloff私はそのアイデアがとても好きです。 行が主要な言語/ライブラリとより簡単にインターフェイスできると便利です。

Jiahaoは、行メジャーと列メジャーのどちらを優先するかはトピックから外れているというのは正しいことです。 その
「ジュリアン」の方法で転置問題を解決するという素晴らしい副作用
（パラメトリックタイプと段階的関数）は、人々により多くの柔軟性を与えます
ストレージ形式。

行/列の特性を配列に追加するというアイデアが気に入らない場合は、
TransposeView {T、N}でもまったく同じことができますが、私は
うまく実装するのはもっと複雑になるのではないかと思います。

追加の特性の最大の欠点は、新しいユーザーの混乱です。
それは私が和解するのに苦労していることです。

2015年9月26日土曜日、スコットP.ジョーンズ[email protected]
書きました：

@tbreloffhttps ：//github.com/tbreloff私はこのアイデアがとても好きです。 それ
言語/ライブラリとより簡単にインターフェースできるようになると素晴らしいでしょう
それは行メジャーです。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-143436947 。

コールオーバーロードはデザインスペースをまったく変更しますか？ 上記の場合、 *意味にある種のあいまいさが存在するように思われることがありました。 特に、 v::Covector * w::Vectorにスカラーを返したい場合、 *実際には行列の乗算ではなく、「 v下にwマップ」するのでしょうか。 もしそうなら、ベクトル自体が共ベクトル上の線形写像であるため、 w::Vector * v::Covectorがスカラーを返すことを同様に要求することはできませんか？

おそらくそれは、代わりに過負荷に役立つだろうcallと書くv(w) "下のマップを示すためにv上の操作" w 、および同様のためのw(v) -どちらもスカラーを返します。 これにより、2次元配列の場合に、配列演算と線形代数演算が共有するセマンティクスに対応するための余裕ができますか？

もしそうなら、ベクトル自体がコベクトル上の線形マップであるため、w :: Vector * v :: Covectorがスカラーを返すことを同様に要求することはできませんか？

私たちは、多くの人が1年生の大学で見ている行列とベクトルの規則に従おうとしていると思います。これは、非可換で、ベクトル*転置ベクトル->行列（ランク1、つまり1つ（非ゼロ）の特異値のみ）を持ちます。値）。 あなたが書いたものは、抽象的な線形代数の概念のように聞こえます。ベクトルとco / dual-vectorは、互いにマップされてスカラーになります。これは問題ありませんが、JuliaとMATLABで試行されるもの（IMHO）とは少し異なります。 あなたが書いたものを内積として解釈できると思います。 dot()または⋅ 、2つの共ベクトル（おそらく共ベクトルに対して定義する必要があります）に作用しますが、外側も必要な場合があります。 -積であり、現在、非累積*使用すると、両方の動作を記述して表現できます。

呼び出し規約v(w)については、ドット積についても同様に、 wの方向にvの量が必要であると言えます。これは、インデックス演算子v[w]を使用することを示唆しています。

同様に、ドット積については、 vの方向にw vの量が必要であると言うことができます。これは、インデックス演算子v[w]を使用することを示唆しています。

この提案は、インデックス作成のセマンティクスにほぼ準拠していますが、準拠していません。 また、 vがVector{<:Integer}場合、ベクトルインデックスの現在のサポートとも衝突します。

v :: Vector{T<:Real}場合、 v[1]は内積v⋅e₁と同等であり、 e₁は最初の軸に沿った標準基底ベクトルであると考えてください。 したがって、単純なインデックス作成は実際には機能です

   v[n] : n :: Integer --> y = (v ⋅ eₙ) :: T

ベクトルインデックスの場合、 v[[1, 2]]は[v⋅e₁, v⋅e₂]を生成します。これは、 {e₁, e₂}またがる部分空間にvを射影した結果であり、同等にv' * [e₁ e₂]結果です。

したがって、ベクトルインデックスは関数です

   v[I] : I :: Vector{<:Integer} --> y = v' * [eₙ for n in I] :: Vector{T}

v[w] = (w ⋅ v) vを作成する提案は、インデックスのコレクションn （ w ）から正規基底ベクトルのコレクションへの暗黙のマッピングを排除するため、この定義と矛盾します。 eₙ 。これは、現在のインデックス作成ルールが機能するために必要です。

今のところ、スコープをベクトル転置だけに制限すると、2つのオプションがあると思います。 エラーにするか、特別なコベクトル型を導入することができます。 ジュリアのベクトルのファーストクラスの性質を考えると、前者は非常に難しい販売になると思います…そしてそれを一貫して行うには、ベクトルが行列の代数に完全に参加することを完全に禁止する必要があります。

それで、私はコベクターを撃ちました。 大変な作業ですが、残念ながらこれ以上時間をかけることはできません。 誰かがそれで走るか、私たちが困難から学び、逃げることを決心することを期待して、私はここにそれを投稿します。 しかし、ビューとして転置を使用するブランチビルディングがあり、行列の乗算はコベクトルで実装されています。 一部の選択されたテストは合格しますが、 depwarn=errorがない場合のみです（例： ./julia -e 'using Base.Test; include("test/matmul.jl")' ）。 https://github.com/JuliaLang/julia/compare/mb/transpose

行列とベクトルのtransposeとctransposeに使用する2つの新しいビュータイプを定義しました。

immutable MatrixTranspose{C,T,A} <: AbstractArray{T,2}
    data::A # A <: AbstractMatrix{T}
end
immutable Covector{C,T,V} 
    data::V # V <: AbstractVector{T}
end

Cパラメーターは、転置が転置であるかどうかを表す単純なブール値です。 CovectorはAbstractArrayサブタイプではないことに注意してください。 これは、ディスパッチを合理的に機能させるための非常に強力な要件です。

いくつかの欠点：

• コベクターは明らかに複雑であり、アクセス可能で厳密な方法で文書化することは困難です。 ここでは言語が役立つかもしれません—単にそれらをRowVectorと呼ぶことができます。 とにかく、この振る舞いを説明しようとするときに最初に直面する問題は、コベクトルの形状について話す方法です（ sizeは未定義です）。 (m,n)が行列の形状である場合、 (m,)はベクトルの形状を表すことができます…そして、タプル表記を乱用する場合、形状が(,n)ようにコベクトルを乱暴に記述することができます
  
  
  
  • 行列*ベクトルは(m,n) × (n,) → (m,)
  
  
  • コベクトル*行列は(,m) × (m,n) → (,n)
  
  
  • ベクトル*コベクトルは(n,) × (,n) → (n,n)
  
  
  • コベクトル*ベクトルは(,n) × (n,) → α （スカラー）
  
  

• ここでの二項演算と型の数は、定義する必要のあるメソッドの数の大幅な組み合わせ爆発につながります…乗算のためだけに：

  • 突然変異:(突然変異、非突然変異）
  • 転置：（A、Aᵀ、Aᴴ）×（B、Bᵀ、Bᴴ）。
  • 形状:(マット×マット; Vec×マット;マット×Vec、Vec×Vec）。 これらのすべてが転置のすべての組み合わせでサポートされているわけではありませんが、ほとんどがサポートされていることに注意してください。
  • 実装：（BLAS、Strided、generic、および構造行列の特殊化）

  これらの操作のいくつかは、複数のディスパッチおよびフォールバック動作とうまく連携しますが、それでも各オペレーターのメソッドの数は_膨大です_。 ここで混合行列/ベクトルのサポートを完全に削除すると、間違いなく物事を単純化するのに役立ちます。



• すべてのスカラー次元を削除する際の問題をすぐに解決するわけではありません。 スカラー次元を削除するときにあらゆる種類のベクトル転置をサポートすると、複素共役に関してあいまいな領域になります（https://github.com/JuliaLang/julia/pull/13612を参照）。 A[1,:]でコベクトルを返すこともできますが、一般化がうまくいかず、スライスから非AbstractArrayを返すのはかなり奇妙です。 人々が＃13612を試して、ベクトルの共役転置が問題を引き起こすケースを具体的に探すことができれば素晴らしいでしょう。現在のベクトル転置セマンティクスでも同様に悪く、Covectorを公開する必要はありません。

いくつかの利点：

• Ax_mul_Bxへの特別な解析の代わりに直接ディスパッチを使用することは大きな勝利です。 それはBLASのAPIで非常にうまく構成されています。 一般に、アルゴリズムの最も内側のレベルで活用したいので、この情報を引数とともに保持する方がはるかに理にかなっています。 BLAS呼び出しの場合、単純な関数を使用して転置文字（ ntc ）を検索できます。
• v'vはスカラーを返すため、ベクトルと共ベクトル間の乗算は結合法則になりました。 v'v*vを左から右に評価し、マトリックスの形成を回避できるようになりました。
• これにより、Vector * Matrixを削除できます。これは、すべてのベクトルを後続のシングルトン次元があるかのように扱う場合にのみ機能します。これは、一般に後続のシングルトン次元のサポートを完全に削除するための大きなステップです。

その他の注意事項：

• ブール型パラメーターで表される転置の複雑さは問題なく機能しますが、パラメーターを間違った順序で定義したように感じることがよくありました。 TとC両方を実際に制限またはキャプチャしたいと思うことはめったにありませんAbstractArray{T}と一致します。
• これは、StridedArrayの問題を実際に悪化させます。 *のメソッドテーブルを読み取ることは、 ::Union{DenseArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2},MatrixTranspose{C,T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},A<:Union{DenseArray{T,1},DenseArray{T,2},SubArray{T,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD},SubArray{T,2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD}}},SubArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD}}ようなタイプでは非常に困難です。 確かに、私はそれをタイプエイリアスとして作成しましたが、これらの異なるタイプエイリアス名をすべて管理するだけでも面倒です（ StridedMatOrTrans 、 QRCompactWYQorTransposeなど）。
• これをSparseVectorと統合する機会はありませんでしたが、CSRを必要とせずに転置を効率的に表すため、これは大きな勝利になります。
• コベクトルにスカラーおよび/または非スカラーインデックスを定義する必要がありますか？ もしそうなら、 r[:]またはr[1:end]の結果は何ですか？ それはベクトルですか、それとも共ベクトルですか？ できれば、これを定義せずに逃げようと思います。 興味深いことに、Matlabには、行ベクトルを他のベクトルでインデックス付けするための非常に特別なルールがあります。奇妙なコーナーケースを犠牲にして、行性を維持しようと非常に努力しています（ r((1:end)')はr(1:end)はr(:)' ）。 今のところ、ブランチでスカラーインデックスを定義していますが、おそらくそれも削除する必要があります。 これにより、Covectorは、それを認識している線形代数演算でのみ使用されることが明確になります。

最後に、ここで見た利点のほとんどは、 MatrixTransposeタイプ自体にも同じように適用できることを指摘したいと思います。 これは、Covectorが抽象代数を深く掘り下げて、ベクトル/行列の混合演算を有効にすることなく、非常にうまく機能することを示していると思います。 それは確かに素晴らしい機能（線形代数と一貫してベクトルを使用する機能）を追加しますが、それが追加の複雑さの価値があるかどうかはわかりません。

好奇心から、 @ mbaumanをまだ覚えている場合、ブールパラメータCを導入する動機は何ですか？ あなたは（疑似特性で）ただ持つことはできません

transpose(::Matrix) -> MatrixTranspose
transpose(::MatrixTranspose) -> Matrix

？ 私はここであなたの（例外的な）判断を疑うことはありません。ただ、どのような認識があなたにこれを強制したのかを理解したいだけです。

おそらく、これをPermutedDimensionArrayタイプに一般化して、順列をエンコードするタプルパラメーターを使用することができます。 Covectorタイプは明らかに異なる目的を持っており、別のものである必要があります。

共役転置（および(A').'非転置共役配列）を処理する方法が必要です。 これを行うための3つの明白な方法があります。

• 1つのMatrixTranspose型内にブールフィールドとして共役を格納します。 振り返ってみると、これは間違いなく外部BLASとのインターフェースに最適なオプションだと思います。 ただし、ネイティブのJuliaBLASに関しては、Julia / LLVMがT.isconjugate ? conj(T[i,j]) : T[i,j]をループから引き上げることができることを確認したいと思います。
• 活用パラメータを持つ1つのタイプ。 これが私が選んだものであり、現在、 Ac_mul_Btや友人を介して共役性の疑似ディスパッチを行っているという事実に影響を受けたと思います。 また、Juliaが実行できるブランチ削除の最適化についてより強力な保証があります。 しかし、私はそれについて一生懸命考えていませんでした…スケッチの実装を始めたかっただけで、Covectorについてもっと心配していました。
• MatrixTransposeとMatrixCTranspose 2つの異なるタイプ。 型パラメーターと同型ですが、2つの別々のラッパー型が煩わしいと思います。 抽象スーパータイプとユニオンエイリアスが役立ちますが、それでもこのオプションではなくパラメーターを選択します。

転置型内に変換関数を格納する型付き関数の4番目のオプションがあると思いますが、関数を高速化するには型パラメーターも必要であり、それも簡単にディスパッチされない型パラメーターです。

ConjugateViewラッパーを使用できるかどうか疑問に思います。ルールconjとtranspose使用すると、 ConjugateViewがMatrixTransposeラッパー内に配置されます。 。 つまり、 A a Matrix場合、
A' = conj(transpose(A)) = transpose(conj(A))すべてMatrixTranspose{ConjugateView{Matrix}}生成します（情報のないタイプのパラメーターを削除します）。

ああ、そうです、それも賢明です。 私は共役転置を1つの原子の「もの」と考える傾向があるので、そのオプションを逃しました。 非共役転置を、形状変更のように、特別なサブ配列インデックスタイプでどのように表すことができるかを考えていました。

皆さんがまだこれに取り組んでくれてうれしいです！ これは壮大なスレッドです！ 3つの歓声!!!

クロスリンクhttps://github.com/JuliaLang/julia/pull/6837#issuecomment-213123832

これは1.0で計画されていますか？

2つの問題（＃18056、＃18136）で、私はこの巨大なスレッドを指摘されました。
だから私はそれを試してみます。

これで、ジュリアは真の1次元ベクトルを持ち、_e.g._ mx[row,:]はもう1xn行列ではありません。
これは歓迎すべき変更です！

しかし、副作用として、いくつかの既存の問題がより明白になりました。
v*mxが1次元ベクトルでは機能しないという事実に噛まれました。
数学的には、自然に機能し、1次元ベクトルを返すはずです。
一般的なa*b製品が契約によって定義されている場合
第1項の最後のインデックスと第2項の最初のインデックス。

現在、Vector-Matrix製品のメソッドシグネチャは次のとおりです。
(*)(A::AbstractVector, B::AbstractMatrix) = reshape(A,length(A),1)*B
そして、この方法を用に使用されているv*v'場合とないためにv*mx 。
（これを指摘してくれた@andreasnoackに感謝します。）
明らかに、単一の方法を両方に使用することはできません。

JuliaはMatlabのようないくつかの慣習に苦しんでいるようです。
しかし、Matlabには、1-dベクトルはなく、1xnおよびnx1行列のみがあります。
自然なことがたくさんあるので、ここで問題が発生する可能性があります。
ジュリアには真の1-dベクトルがあり、これは大きな利点になるはずです。
それ自体の本当に一貫した状態に到達するのは素晴らしいことです。

この場合、Fortranは、従うべきはるかに優れた、より一貫性のある例です。
transpose演算は、Fortranの行列に対してのみ定義されています。
真の1-dベクトルから1xn行列を作成することは、単に転置ではありません。
matmulについては、＃18056で引用されているメットカルフの本の抜粋を参照してください。

@alanedelmanの元々のポイントのほとんどは

だからここにいくつかの既存の問題を単に治すであろう提案があります、
現在の状態を可能な限り尊重しながら：

• 真の1次元ベクトルから1xn行列を作成するためにv'をそのまま保持しますv
• rowmxおよびcolmx関数の方が優れていますが、 v'は広すぎて変更できません
• 真の1次元ベクトルを作成するためのvec関数がすでにあります
• v'の逆数はv''なくvec(v') 、私たちはそれと一緒に暮らすことができます
• a*bの製品は、常に最後のインデックス契約する必要がありaとの最初のインデックスb
• *演算子は、内積にも外積にも使用しないでください
• 内積については、すでにdot関数があります
• 外積の場合、 *の使用を排除する必要があります（つまり、 v*v'構文）
• 外積の場合は、新しい機能を使用する必要があります
• 対応する中置演算子は構文を軽く保つことができます

[の簡潔な数学的構文]の外積を失うことは残念なことです。 個人的にvec * matをあきらめたいです。

既存のPernutedDimsArrayは、親とビューの次元数が異なる場合をすでに処理できますか？ もしそうなら、多分それはベクトルの親のためにさえ非共役転置ラッパータイプとしてすでに使用可能です。

ドキュメントにPermutedDimsArrayが見つかりませんでした。

しかし、私は、さらに多くのデータ型を発明する代わりに、
3種類のアレイ製品のみを明確に分離する必要があります。
内積はすでに分離されています。
通常の製品と外積を分離するだけで済みます。
外積は失われず、構文のみが変更されます。
v*mx場合は、より深刻な問題の兆候としてのみ考慮してください。

「メソッドの欠落の問題」を除けば、心配する必要のあるタイプではなく、 .'が遅延ラッパータイプ（および'返す実装の詳細になります。その共役バージョン）。 そうでなければ、 vec*matとvec*vec'両方が同じ*演算子を使用することはできないと思います。 論文でvec*matを見た場合、それは私には間違っているように見えますが、 vec*vec'かなり頻繁に見られます。

しかし、もっと考えてみると、PermutedDimsArrayはその要素を配列の配列に再帰的に転置しないので、ここで使用するラッパー型としてはあまり適していません。

もう1つの方法は、ベクトル転置を完全に禁止することです。 ここでの議論はすでに徹底しすぎていると思います。影響がどのようになるかを評価するために、一方または両方のオプションの包括的な実装を待っています。

このスレッドが終わりに近づいている間、あなたが議論の準備ができていたことに感謝します。

v*mxは奇妙に見えるかもしれませんが、結晶学的コードで頻繁に使用されます。
また、Fortranのmatmulによって適切に処理されます。 （＃18056を参照）

u*v'製品に戻ります。
uとvが両方ともnx1行列の場合、これは正規行列の積です。
これは、外積と同じ結果を提供することがわかります。
しかし、これは外積をエミュレートするために行列積を使用しているだけです。
これは、すべてがマトリックスであるMatlabの世界ではシームレスです。

Juliaには、Fortranの世界に近い真の1次元ベクトルがあります。
ジュリアでは、転置ベクトルv'はすでに問題になっています。
他の人がジュリアにすでに提案したように、Fortranの選択はそれを禁止することです。

Fortranには、外積の組み込み関数はありません。
ジュリアはv'を1xn行列に簡単に変換します。
そして、1-dベクトルと1xn行列に対して*演算を実行します。
複数のディスパッチがあるため、これを行うことができます。
しかし、ここでは*は確かにもはや行列積ではありません。

FortranとJuliaが同じように動作するポイント
どちらも内積に対して個別のdot関数を使用するということです。
dotも*演算子にバンドルするという議論がありました。
しかし幸いなことにそれは起こりませんでした。

したがって、線形代数の3つの積を処理する必要があります。
通常の行列積、内積、および外積。
現在、 *演算子は、通常の製品と外積を組み合わせた構文です。
私が提案したのは、これらを分離して、より一貫した状態に到達することだけです。

（ああ、外積を省略しましたが、すでに十分に分離されています）

内積、外積、および行列乗算は、積を分割/分類する数学的に適切な方法ではないと思います。 以下は確かに様々な人が上で述べたことの繰り返しですが、このトピックの長さを考えると、時々要約を含めても大丈夫だと思います。 これは私の個人的な要約であり、私は確かに専門家ではないので、間違っている場合は訂正してください。

抽象線形代数設定では、主なプレーヤーはベクトルv （ベクトル空間V住んでいる）、線形マップ（1つのベクトル空間V作用し、おそらく異なる空間W ）とこれらのマップの構成、線形形式または共ベクトル（デュアル空間V*住み、 Vからスカラーへのマッピング）、内部積（ V × Vからkron ）。 外積私はベクトルと共ベクトルの間のテンソル積として考えることを好みます。

この問題で特に興味深いのは、内積が定義されている場合のベクトルと線形形式の間の同型です。つまり、ベクトルvをスカラーにマッピングするすべてのfに対して、 wが存在します。その結果、 f(v) = dot(w,v)の任意のためのv 。 ただし、共ベクトルは内積（多次元関数の勾配など）を参照せずに存在できます。

コンピューター上でこれらすべてのオブジェクトを表すには、通常、基底を選択し、行列代数を使用してこれらのほとんどを表すことができます。 つまり、後続のシングルトン次元（nx1行列としてのベクトル、1x1行列としてのスカラーなど）に柔軟に対応できる場合にのみ、行列の乗算と転置が必要になります。 これはMatlabの見解であり、特に数値線形代数で多くの本や論文が書かれている方法でもあります。

その場合、ベクトルから共ベクトルへの前述の同型写像（暗黙的にユークリッド内積を仮定）は、ベクトルの行列表現の転置（複素数の場合はエルミート共役）を取ることに対応します。 ただし、抽象的な意味では、ベクトルの転置の概念はありません。これが、 @ GaborOszlanyiで述べられているように、Fortranで定義されていない理由

Juliaコードでは型の安定性が重要であるため、Matlabの「唯一の行列」（柔軟な末尾のシングルトン次元を使用）アプローチはうまく機能しません。 しかし、完全に抽象的な設定に移行して、通常の設定（ユークリッド内積、ベクトルからコベクトルへの簡単なマッピングなど）で作業を続けたくもありません。 最終的にコードを記述し、ASCII文字を使用したいので、記号* 、 ' 、および.'から可能な限り絞り出す必要があります。 幸いなことに、これは複数のディスパッチが役立つ場所であり、上記のさまざまな提案につながります。 これについて、つまり、抽象的な線形代数演算が特定のジュリアメソッド（関数ではない）にどのように変換されるかについて表を作成しました。

@GaborOszlanyiへの最後のメモとして、私はまだこれらすべてにv*Aの場所を見つけられません。 これは、ベクトルがデフォルトで行行列として示されるフィールドでは標準的な場合がありますが、個人的にはこれは奇妙な選択だと思います。 線形写像fとgがf(v) = v*Aとg(v) = v*Bとして機能する場合、これはg(f(v)) = (g ◦ f)(v) = v*A*Bを意味します。交換されます。 リンクされたテーブルの最後から2番目の行のように、これを不完全な内積として解釈できます。

あなたの要約は深くて説得力があります。
よく説明していただきありがとうございます。

残りの質問は2つだけです。

• この徹底的な議論の結果、ジュリアでは実際にどのような変化が起こるでしょうか？
• なぜFortranはv*mxにmatmul v*mxを実装したのですか？

この問題によって明らかになる2つの問題があります。

A.応用数学者は、2つの自然な同型写像を暗黙的に利用するハウスホルダー表記法に縛られています。

1. Nx1行列はベクトル空間を形成するため、長さNのベクトルはNx1_列行列_と区別できません。 （ "columnify"、▯）
2. 1x1行列はスカラーのすべての代数的特性で定義できるため、1x1行列はスカラー数と区別できません。 （「スカラー化」、■）

問題は、これらの同型写像のどちらもJuliaの型で表現するのが自然ではなく、どちらも配列形状の実行時チェックを伴うことです。 MATLABの後続のシングルトン次元ルールは、これらの同型の両方の実装と考えることができます。

B. 2次元配列は、配列の配列として再帰的に定義できます。 ただし、行列は列の行または行の列ですが、行の行または列の列ではありません。 行列を再帰的に定義できないという事実は、行列とn次元配列の異なるテンソル構造を強調しています。 正しく言えば、多次元配列は非常に限られた種類のテンソルであり、後者を実装するために必要な完全な機構を欠いています。 厳密に言えば、縮約はベクトル空間とその双対のペアに対する操作であるため、双対ベクトル空間の概念を呼び出すことのない多次元配列のインデックスの縮約について話すのは誤った呼び方です。 ほとんどの人は完全な機械を望んでいません。これには、行/列の性質を持つ共変性/反変または上/下のインデックスについて心配する必要があります。 代わりに、ほとんどの人は、配列がすべての次元で完全に逆変であり、_2次元を除いて_、2次元配列を行列の代数（ダウンアップテンソル）を持つものと考えたいと考えています。ダウンダウン、アップアップ、またはアップダウンテンソル。 言い換えれば、2次元配列は特殊なケースになりたいのです。

そうでなければ私はまだ説得される可能性がありますが、これが私の現在の3部構成の提案です：

a）ベクトルの転置を完全に禁止し、 u'v 、 u*v' 、 u'*A*v 、 u'*A*v/u'vなどのハウスホルダースタイルの式を作成するために、ユーザーがベクトルを列行列に明示的に変換する必要があるuとvが真のベクトルである場合、特別なTransposedVectorを導入せずにu'やu'*Aような部分式を与えることはできません。 TransposedVectorタイプ。論理的帰結として、多次元配列がテンソル構造のアップ/ダウンインデックスについて心配する必要があります。これは、支払うには高すぎるようです。

（a）の制限は、すべてのHouseholderスタイルの式が真のスカラーの代わりに1x1行列を生成することです（これは、1ベクトルを返すu'vよりも大幅に改善されています）。したがって、 (u'*v)*wような式は

b）次のようなベクトルに対する類似の演算の代替表記法を導入します。

• 内側（ドット）積のu ⋅ v = scalarize(columnify(u)'*columnify(v))
• アウター（クロネッカー）積のu ⊗ v = columnify(u)*columnify(v)'
• A(u, v) = scalarize(columnify(u)'*A*columnify(v)) 、双線形形式の古い表記
• 二次形式の場合はA(u) = A(u, u)

（b）の式は、内積および双線形/二次形式の式を自動的にスカラー化することにより、（a）の式とは異なり、1x1行列の形成を回避します。

c）1x1行列を真のスカラーに変換できるようにして、次のようなコードを作成します。

M = Array(Int, 1, 1, 1)
a::Int = M

動作する可能性があります。 必要なのは、次のような配列サイズの実行時チェックを行うことだけです。

function convert{T}(::Type{T}, A::Array{T,N})
    if length(A) == 1
        return A[1]
    else
        error()
    end
end

この提案は、約2年前にFolkmarBornemannによって提案されたものを少し変更したものです。 私たちが試したところ、実行時チェックのコストはそれほど大きくなく、一般的な割り当てではなく、型強制割り当て（実際にはconvert偽装呼び出し）でのみ呼び出されました。

@jiahao 、この投稿の読みやすさは、レンダリングが難しい文字によって制限されています。 通常、フォントにほぼ完全にUnicodeが含まれているOSXでは正しく表示されません。

@jiahao 、私は確かにそのほとんど/すべてに同意することができ

特別なTransposedVectorタイプを導入せずに、論理的帰結として、多次元配列がテンソル構造のアップ/ダウンインデックスについて心配する必要があります。これは高すぎると思われます。

あなたがしたい場合にのみ、私には論理的帰結だTransposedVectorのサブタイプAbstractArray私は計画ではなかったと仮定階層、（いくつかのとは異なり、 LazyTranspose真のタイプどのは別の種類のAbstractMatrix ）。

アウター（クロネッカー）積のu ⊗ v

暗黙の同型写像に依存せず、行列演算をベクトル演算やより抽象的な積からきれいに分離することが目標である場合、これは次の理由で失敗すると思います（次の数学的定義に関する普遍的な合意についてはわかりません）。

• クロネッカー積A ⊗ Bは、ベクトルではなく行列で定義された演算です。
• したがって、 u ⊗ vを2つのベクトルのテンソル積として読み取る代わりに、これにより、ダウンダウンタイプの2次元テンソルが生成されます。 適切な「行列」を取得する唯一の方法は、ベクトルとコベクトルのテンソル積を取ることです。 しかし、これらのオブジェクトの導入を避けたいので、関係する2つのベクトルを列化する前にこの操作の結果を取得することは不可能のようです。
• u ⊗ vの3番目の名前は、通常はだらしなく定義されている外積であり、上下に関して受け入れられている厳密な定義があるかどうかはわかりません。 一部の情報源は、2つのベクトルのテンソル積、つまり前のポイントと同等であると述べています。 代わりに、「外積」が2番目のベクトルをコベクトルに暗黙的にマッピングしてダウンアップテンソルを取得することも意味する定義を受け入れる場合、問題はありません。

代わりに、ほとんどの人は、配列を単純な古いコンテナーにし、2次元を除くすべての次元で完全に反変にすることを望んでいます。

核の選択肢を検討しましたか？ 線形代数を最初からやり直し、 AbstractVectorとAbstractMatrixの型エイリアスを完全に削除して、次のように置き換えます。

abstract AbstractVector{T} <: AbstractArray{T,1}
abstract AbstractMatrix{T} <: AbstractArray{T,2}

# and we could introduce:
abstract AbstractCoVector{T} <: AbstractArray{T,1}

フォールアウトがたくさんあることは理解していますが、多次元ストレージ配列と線形代数が明確に分離される可能性があります。 完全な多次元テンソル代数、双対ベクトル空間などを実装する必要はありません。ベクトル、共ベクトル、行列など、多くの人が必要とするビットを実装する必要があります。 内積、外積、covector-matrix製品、matrix-vector製品、matrix-matrix製品を取得します。 転置は、上記のすべてで定義されています。 1D配列の1D配列を実際に使用するAbstractMatrix実装を作成できます（もちろん、デフォルトの実装ではありません）。 Householder表記（IMHOはMATLABの弱点の1つです！）を使用する必要はありませんが、線形代数のすべての便利さを得ることができます。

これを提案するのは少し緊張しますが、ジュリアは、ハウスホルダーの慣習にフォールバックする必要なしに、ほとんどの人が大学レベルの線形代数などで学ぶことの「正しい」モデルを模倣できると思います。 明確に区別することで、 Base.LinAlgを「標準ライブラリ」パッケージに移動するのも簡単になるかもしれません。これはJuliaの長期的な目標だと思いますか？ また、新しい1Dサイズ変更可能なリストのようなものが新しいBuffer変更とArrayネイティブ実装に付属するという考えともよく一致するため、この一般的な「リスト」タイプJuliaのコア部分の多くでVectorを置き換えることができ、 Arrayと「リスト」をかなり早く定義しながら、 LinAlgパッケージをかなり遅くロードできます。

すでに「ダミングダウン」されており、適切な線形代数ではなく、Fortran配列で表現されているアルゴリズムが多数存在します。 Juliaは、多次元配列の上に線形代数構造を再発見（または強制）する必要なしに、これらのアルゴリズムを実装できる必要があります。

私の仕事では、テンソルや共変性と反変のインデックスなどをFortran配列にマッピングする適切な線形代数がおそらく最適です。 この作業を行うために、そして人々を混乱させないために、私は「ベクトル」、「マトリックス」、「配列」という用語をそのままにして、それらを低レベルに保ち、他の（より派手な？）用語をすべての高レベルに使用します。 上記の上位レベルは、抽象型またはパラメーター化のいずれかを介して、ストレージオプションも抽象化する必要があります。 たぶん、接頭辞LAは、これを表現する方法です。

LA.Vector
LA.CoVector
LA.Tensor{... describing co/contravariance of indices ...}

次に、ベクトルと行列は純粋にストレージに使用されます。 低レベルでは、転置は手動で管理されます（BLASと同じ）。 高レベルでは、自動的に処理されます。

これは、下位互換性を壊さず、Matlab / Fortran / numpy convertの期待を壊さないことを除いて、 @ andyferrisの提案に近いもの

@eschnettこのスレッドの前半で、ベースのJuliaではなく、多重線形代数をパッケージに残すことが決定されたと思います。 あなたが提案するようなこれらのアイデアの多くは、型システム内のテンソル、ベクトル空間、共/逆分散などを扱う新しいパッケージで具体化できると思います。これは、便利な関数を提供する_TensorOperations.jl_パッケージとは多少異なります。テンソルであるかのように配列を乗算します。 開発するのは難しいと思いますが、潜在的に価値のある抽象化です！

MatrixとVectorをそのままにしておくことに関しては、おそらく現在の定義は完璧であるか、標準的な数学を使用して行列を乗算し、ベクトルを転置したい人々のために私たちができるより良い何かがあるかもしれません表記。 システムが明白で雄弁であり、他の言語での_改善_であれば、簡単に習得できるはずですが、新しいユーザーに小さな学習曲線を追加する可能性があると思います。

一般的な非ユークリッド複素ベクトル空間Vは、 V 、 conj(V) 、 dual(V) 、 conj(dual(V)) 4つの関連空間があることに注意してください。 したがって、一般的なテンソルには4種類のインデックスがあります（通常、上または下、禁止または禁止なしとして示されます）。 複雑なユークリッド空間（量子力学など）では、 dual(V) ≡ conj(V)とconj(dual(V)) = V 。 実際の（非ユークリッド）空間（一般相対性理論など）では、 V ≡ conj(V) 。 後者の場合の両方で、アップインデックスとダウンインデックスのみが必要です。

実際のユークリッド空間（ほとんどのアプリケーション？）では、それらはすべて同等であり、テンソルを表すにはジュリアの単純な配列で十分です。 したがって、少なくとも実数の場合、次の2つの操作により、完全で一貫性のあるテンソル代数を構築できます。

• コントラクト/内積∙ 。これは、次のルールを使用してランクN任意の配列に一般化できます。最初の配列の最後のインデックスを2番目の配列の最初のインデックス（またはnumpyのdot規則ですが、直感的ではありません）、 AとBランクがM場合、 A ∙ BはランクM+N-2配列を返します。 MおよびランクN 。
• テンソル積⊗ ： A ⊗ BはランクN+M配列を返します

ベクトルv 、 wおよび行列A 、 Bに特化しているため、次のすべてを記述できます。

• ベクトル内積v ∙ w ->例外的に、ランク0の配列ではなくスカラーを返します
• 行列ベクトルの乗算A ∙ v
• 行列行列の乗算A ∙ B
• テンソル/外積v ⊗ w
• コベクトル（===ベクトル）行列の乗算v ∙ A

∙に*を使用したい場合もありますが、落とし穴は、上記の∙定義が結合的ではないことです。 (A ∙ v) ∙ w ≠ A ∙ (v ∙ w)は、後者でもないためです。定義されます。

しかし、繰り返しになりますが、それは、複雑な配列を無視しても構わないと思っている場合に限ります。

テンソルの完全に一般的な実装に関しては、スタックに割り当てられたタプル、生成された関数、およびおそらく今日それをより実現可能にする他のすべての機能が存在する前に、私はこれをずっと前に開始（および放棄）しました。

興味深いアプローチ、@ Jutho。 十分直感的に思えます。 *と'で何をするかに関係なく、これらの定義を追加できると私は_推測_しており、それをサポートします。

しかし、繰り返しになりますが、それは、複雑な配列を無視しても構わないと思っている場合に限ります。

手動で挿入されたconj()修正します。 そして、ジュリアは複雑な行列を無視したいとは思わないでしょう？

AbstractMatrixをタイプエイリアスではなく特別なサブタイプとして使用することについて、さらにいくつか気づきました。

matrix[:,i] -> AbstractVector{T}
matrix[i,:] -> AbstractCoVector{T}
array_2d[:,i] -> AbstractArray{T,1}
array_2d[i,:] -> AbstractArray{T,1}

これはかなりクールです-行列のインデックスから列と行のベクトルを取得できます。 2Dストレージコンテナの場合は、1Dストレージアレイを取得します。 すべてのユースケースをカバーする必要があります！ また、 AbstractVector{T} <: AbstractArray{T,1}とAbstractCoVector{T} <: AbstractArray{T,1}両方があるため、APLスライシングルールを使用したAbstractArrayインターフェイスに従います。

1つの「興味深い」事実は

array_3d[:,:,i] -> AbstractArray{T,2}
matrix(array_3d[:,:,i]) -> `AbstractMatrix {T}

そのため、結果を行列乗算する場合は、手動で行列としてラップする必要があります。 これはプラスかマイナスか、わかりません。 しかし、これは潜在的な問題の1つであるように思われ、ストレージと線形代数を混同する他の言語のユーザーが簡単に使用できるようにすることについて

これはばかげた質問かもしれませんが、 @ juthoは、コードの記述はASCIIによって制限されていると前述しました。 なぜ世界で、1963年に開発され、1986年（30年前）に最後に更新された7ビットの文字セットに制限されているのでしょうか。 これは、有名な640KBが1981年にPCで利用可能な最大RAMであった時代でした。今日のコンピューター市場では、現在、32GBのRAM（以前の最大値の50,000倍）を備えた64ビットプロセッサが一般的に販売されています。 64ビットプロセッサの理論上の制限。 では、なぜ40年前に開発された文字セットに限定しているのでしょうか。

ユニコードを使用できますが、残念ながら、キーボードのサイズは過去40年間、通常の人が持っている指の数（過去10000年以上）も同様の要因で拡大しなかったことを覚えておいてください。

私見、ASCIIは休ませる必要があります。 高速な数学シンボルプログラミングのための特別な数学キーボードは、実際には良い考えです！ UTFに付属するシンボルをこれ以上使用しない正当な理由はありますか？ ASCIIから可能な限りすべてを搾り出そうとする苦痛を正当化できますか？

@ esd100 ：このような非常に投機的な議論には、このGitHubの問題を使用しないでください。

@Johnmyleswhite。 「投機的」とはどういう意味かわかりません。 それがあなたが使うつもりだった言葉だと確信していますか？ 言語、演算子、機能は使用されている記号に関連しているように見えるので、ASCIIと他の何かの使用が議論に関連していると思いました。 私は決して専門家ではありませんが、対処されている機能に関連して議論するか、少なくとも明確にすることに関する問題のようです。

つまり、言語を希望どおりに定義できない理由はありますか（基本的な目標である使いやすさ、速度を念頭に置いて）？ 特別な記号/単語を使用すると、言語がより豊かで美しくなりませんか？

（2つのUnicodeの記号を使用して）例えば@Juthoさんの最新のコメントが好評と@yuyichaoは、我々はUnicodeを使用できることに同意したこと@ ESD100してくださいノート。 より多くのUnicodeのみの演算子を導入することについての他の提案があります（例えば、関数を構成するための構成記号、＃17184）。 人々があなたに反対しているとは思いませんが（私たちは心に留めておくべき実際的な考慮事項がありますが）、あなたが_特定の_、トピックに関する提案がある場合は私たちに知らせてください。

v0.5でのこの新しい動作に少し混乱しています。これは、この議論から生じたと思います。

julia> [ x for x in 1:4 ]' # this is fine
1×4 Array{Int64,2}:
 1  2  3  4

julia> [ Symbol(x) for x in 1:4 ]' # bit this isn't? What is special about symbols?
WARNING: the no-op `transpose` fallback is deprecated, and no more specific
`transpose` method for Symbol exists. Consider `permutedims(x, [2, 1])` or writing
a specific `transpose(x::Symbol)` method if appropriate.

リスト内包表記から（数値以外の）行ベクトルを作成するにはどうすればよいですか？ 行ベクトルである必要があります。 （これは別の問題として、または他の場所で議論する方が良いでしょうか？どこに投稿すればよいかわかりませんでした...）

reshapeを使用できます： reshape(v, 1, length(v)) 。 たぶん、これは非推奨の警告でも言及されるべきですか？ 転置は数学演算であるため、数学的なベクトル/行列に対してのみ定義する必要があるという考えだと思います。

それはdepwarnで言及されています： permutedims(x, [2, 1]) 。

permutedimsはベクトルに対しては機能しません。 この真新しい問題を参照してください：＃18320

転置は数学演算であるため、数学的なベクトル/行列に対してのみ定義する必要があるという考えだと思います。

これは私には意味がありません。 これは議論の余地がありますか？ 本当に正当な理由がない限り、私は本当に転置して非数値配列で作業することを好みます。

転置は数学演算であるため、数学的なベクトル/行列に対してのみ定義する必要があるという考えだと思います。

これは私には意味がありません。 これは議論の余地がありますか？ 本当に正当な理由がない限り、私は本当に転置して非数値配列で作業することを好みます。

私は、あなたが望むものを満足させることは比較的複雑であり、数学にとって意味があると思います。 数学的な意味では、転置は、ベクトル空間とベクトルまたは行列のそれらの双対空間を交換することによって定義されることがよくあります（まあ、転置と共役転置にもいくつかの複雑さがあります）。 ハミング数の行列Mの場合、転置はpermutedims(M, (2,1))になりますが、一般に、次のようなサブ行列の観点から「ブロック」行列を定義できます。

M = [A B;
     C D]

ここで、 Aなどは行列そのものです。 私の理解では、ジュリアは

M' = [A' C';
      B' D']

これは、ペンと紙の数学を使用して行うことであり、したがって「望ましい構文」です。

これは、行列の要素が'と.'を受け入れる必要があることを意味します。 数値の場合、これらはそれぞれ複素共役と無演算として定義されます。 IMHOこれは便利な駄洒落だと思いますが、機能し、最も重要なのは、_simple_ルール（「転置は再帰的」- BlockMatrixクラスなどを必要とするのではなく）で実装されることです。 しかし、この転置の駄洒落は、あまり意味がないため、0.5では非数値タイプから削除されました。 Symbolの転置は何ですか？

数値ではなく_data_がある場合、 permutedimsは、その意味と動作が完全に明確に定義されています。つまり、再帰的ではありません。 .'ような数学の駄洒落を使用すると、数文字の入力を節約できますが、他の誰か（数学やMATLABにあまり詳しくない人）がコードを使用している場合は、コードを読む方が理にかなっています。必要に応じてreshapeとpermutedims 。 _私にとって、これは_最も_重要なポイント_です。

私見では、この非常に長い問題は、線形代数の数学的に一貫したインターフェースを作成することに関するものであり、結果としてデータの配列の数学的なしゃれが少なくなるのは自然なことのようです。

思いやりのある対応をありがとう。 私はまだかなり強く反対します

しかし、この転置の駄洒落は、あまり意味がないため、0.5では非数値タイプから削除されました。 シンボルの転置とは何ですか？

Symbolの転置をno-opとして定義することは、実数で転置を定義することよりも意味がないかどうかわかりません。 「しゃれ」は便利だと思いますが、「適切な」ことは、ベクトルと行列に対してのみ転置を定義し、 transpose(A::Matrix{Complex}) conjをの一部として

.'ような数学の駄洒落を使用すると、数文字の入力を節約できますが、他の誰か（数学やMATLABにあまり詳しくない人）がコードを読んでいる方がはるかに理にかなっています。必要に応じて形状を変更し、並べ替えます。 私にとって、これが最も重要なポイントです。

.'は慎重に使用する必要があり、 transposeをより明示的に呼び出す方がよい場合が多いことに同意します。 reshapeとpermutedimsは、そもそも読み取りとコーディングを行うために、取るに足らない量の認知オーバーヘッドを必要とする可能性があると思います。 正直に言うと、解析が速くなります。

transpose([ f(x) for x = 1:length(A) ])
reshape([ f(x) for x = 1:length(A) ], 1, length(A))

このような単純な場合でも、何が起こっているのかを理解するために、行の最初（ reshapeを読み取る）から最後（ length(A)を読み取る）までバウンスする必要があります。 （次に、 length(A)が最初に存在する理由を理解するために、途中に戻って作業する可能性があります。）

私にとって、より大きな問題は、私が新しいJuliaである場合（つまり、以前にnumpyとMATLABを使用したことがある）、これが機能することです。

[ x for x = 1:10 ]'

文字列や記号などの配列でも同じことが機能すると当然想定します。 .'のセマンティクスを理解するために長いオンラインディスカッションを読むつもりはありません-私はいくつかのことを試して、過去の経験から一般化/推測します。 おそらく、より良いエラーメッセージがあるとここで役立つでしょう。

全体として、 Symbolやその他の非数値入力でno-op転置を維持することが、ここで提案されている優れた数学的フレームワークにどのように干渉するかはわかりません（価値のある目標です！）。 しかし、ノーオペレーションを維持することは無害のようです。

しかし、ノーオペレーションを維持することは無害のようです。

すべてがAnyサブタイプであるため、 Anyに対して意味のあるものを定義することはできません。 定義transpose(x)=xは、どの種類の行列に対しても明らかに間違っており、サイレントエラーの一部を回避するために、これらの定義を追加'を完全に非数学的な演算で許可することと、サイレントエラーを回避することのトレードオフです。

シンボルの転置をno-opとして定義することが、実数で転置を定義するよりも意味がないかどうかはわかりません。 「しゃれ」は便利だと思いますが、「適切な」ことは、ベクトルと行列に対してのみ転置を定義し、 transpose(A::Matrix{Complex}) conjをの一部として

私は完全に同意しませんが、ある種のBlockMatrixを実装するか、 Matrix{M<:Matrix}に対して特別なメソッドを定義する必要があります。 どちらが人気のあるアイデアかわかりませんか？ （これは、これらの関連する問題のいくつかを単純化する可能性があるため、フォローしている人にとっては深刻な質問です）。

正直に言うと、解析が速くなります。

transpose([ f(x) for x = 1:length(A) ])
reshape([ f(x) for x = 1:length(A) ], 1, length(A))

2つ目は、ジュリアの現在のベクトルの転置とは関係がないためです（明らかに、_私はベクトルの転置を取ります_rowvec = reshape(colvec, (1, n))と記述します。 [f(x) for _ = 1:1, x = 1:n]は、最初から正しい形を作るように理解を強制します。または、 .'が本当に好きな場合は、 map(f, (1:n).')とf.((1:n).')現在機能します。

これは、完全に非数学的な操作のために比較的奇妙な構文を許可するという便利さと、サイレントエラーを回避することの間のトレードオフです。

これがサイレントエラーやその他の問題を引き起こしていた場合、私はおそらくこの議論を失うことになると思います。 （なぜエラーが発生するのかわかりませんが、私はあなたを信じています。）一方、...

ある種のBlockMatrixを実装するか、Matrix {M <：Matrix}に対して特別なメソッドを定義する必要があります。

私は間違っているかもしれませんが、あなたは2番目を行う必要があると思います。それは私にとって合理的な選択肢のようです。 しかし、これは私の給与水準を上回り始めています。

[_ = 1：1、x = 1：nの場合のf（x）]

これを忘れた！ これはおそらく私がやることになることです。 全体的に、私はまだ読みやすいコードに対するあなたの好みに同意しませんが、それぞれ彼/彼女自身に！ ¯\_(ツ)_/¯

明らかに、私はベクトル転置を真剣に受け止めています

はい。 私はそう思う。 😉

これ（https://github.com/JuliaLang/julia/issues/16790）でも、 transpose代わりにreshape 、少し味が良くなります。

私は間違っているかもしれませんが、2番目を実行する必要があると思います（編集： Matrix{M<:Matrix}に対して特別な転置メソッドを定義します）。これは私には合理的なオプションのようです。

残念ながら、データと線形代数の違いに再び戻ります。 線形代数ブロック行列に再帰的転置を持たせたいが、2Dデータ配列の一般的な2Dデータ配列には再帰的転置を持たせたくない...しかしMatrix{T}とArray{T,2}は同じものですが、私たちはできませんそれを行う。

これ（＃16790）は、転置の代わりにreshapeを使用することで、私にとって少し口当たりが良くなります。

本当!!

線形代数ブロック行列に再帰的転置を持たせたいが、2Dデータ配列の一般的な2Dデータ配列には再帰的転置を持たせない

これは私が明らかに望んでいることではないようです...これらの異なる種類の転置を処理するための2つの異なる関数を持っていないのはなぜですか？ 線形代数オブジェクトとデータオブジェクトの間に非常に厳密な区別があるというメモを見逃したと思います。

このスレッド全体を読むのは大変な作業のように思えますが、さらにコメントする前にそうする必要があるかもしれません。 知らないうちにノイズを加えたくない。

線形代数オブジェクトとデータオブジェクトの間に非常に厳密な区別があるというメモを見逃したと思います。

線形代数オブジェクトとデータオブジェクトの間に厳密な区別はありません。
現在の実装でも、理想的な使用でもありません。

存在する場合、サイズの変更（ push! ）または線形代数オブジェクトの値の変更はサポートされません（そのようなユーザーはStaticArrays.jlなどを使用します）。 broadcastのみがサポートされます。線形代数オブジェクトでサポートされます。
データオブジェクトは、拡張、変更可能となり、かつ支持するだろうmap 、（およびreduce 、およびfilter ）ではなくbroadcast 。

しかし、私たちは人々がデータオブジェクトのバイナリと線形代数オブジェクトのどちらかを考えている世界にいません。
したがって、この2。5年、340コメントスレッド。

no-op転置について。
型階層の非常に高い位置に、 ScalarとNonscalar抽象型を追加できます。
Scalarsすべて、操作なしの転置へのフォールバックです。
Nonscalarsはフォールバックはありません（ただし、現時点では非推奨の警告にフォールバックします）

数字、文字、文字列、そしておそらくタプルでさえScalarなり、操作なしの転置が定義されます。 一部のスカラー、たとえば複素数は、この転置の定義を上書きします。

配列（行列、ベクトルなど）は、 Nonscalarサブタイプであり、再帰的な転置を持ちます。

それが好きかどうかはわかりません。

最近の一連の投稿は、＃18320＃13171＃13157＃8974の_matrixtranspose_および "scalar"タイプに関する議論を再構築しています。

transpose(x)=x no-opフォールバックは無害であるという考えを本当に払拭したいと思います。 私の考えでは、フォールバックは、最適化されたアルゴリズムよりもゆっくりと、正しい結果を生成するはずです。 フォールバックメソッドが誤った答えをサイレントに計算する場合、フォールバックに正しいセマンティクスがないことを意味するため、危険です。 transpose(x)は、 xタイプに応じて異なる意味を持ちます。

no-op転置フォールバックは、行列の行列に対して間違っているだけでなく、 AbstractMatrixサブタイプではないすべての行列のようなオブジェクトに対しても間違っています（これは、＃987によって、エントリが明示的に格納されていることを意味します。それらが行列の代数を持っていること）。 これが1つのポスターの子の例です（かなりの数があります）：

julia> A = rand(5,5); F = qrfact(A); R = F[:R]; Q = F[:Q] #Q is an example of a matrix-like object
5x5 Base.LinAlg.QRCompactWYQ{Float64,Array{Float64,2}}:
 -0.518817    0.0315127   0.749223    0.410014  -0.0197446
 -0.613422   -0.16763    -0.609716    0.33472   -0.3344   
 -0.0675866   0.686142    0.0724006  -0.302066  -0.654336 
 -0.582362   -0.0570904   0.010695   -0.735632   0.341065 
 -0.104062    0.704881   -0.248103    0.295724   0.585923 

julia> norm(A - Q*R) #Check an identity of the QR factorization
8.576118402884728e-16

julia> norm(Q'A - R) #Q'A is actually an Ac_mul_B in disguise
8.516860792899701e-16

julia> Base.ctranspose(Q::Base.LinAlg.QRCompactWYQ)=Q; #Reintroduce no-op fallback

julia> norm(ctranspose(Q)*A - R) #silently wrong 
4.554067975428161

この例は、何かがAnyサブタイプであるからといって、それがスカラーであり、操作なしの転置があると想定できることを意味するわけではないことを示しています。 また、OPの親の問題を解決するのが非常に難しい理由も示しています。 行列のような非配列オブジェクトQの場合、 Q'は配列操作としての実際の意味はありませんが、明確な代数的意味があります。 Q'Aような式は完全に明確に定義されています。 線形代数ではなく配列を扱う他の人々は、単に非再帰的な並べ替えを必要とし、行列のような非配列を気にしません。 それにもかかわらず、すべてのタイプの代数的セマンティクスと軸交換セマンティクスの両方の一貫したスペルを持つことはできないという事実が残っています。

たぶん私は密集していますが、比較は次のようになると思いました。

julia> A = rand(5,5); F = qrfact(A); R = F[:R]; Q = F[:Q]
julia> Base.ctranspose(Q::Any) = Q;
WARNING: Method definition ctranspose(Any) in module Base at operators.jl:300 overwritten in module Main at REPL[6]:1.
julia> norm(ctranspose(Q)*A - R) # still works fine
4.369698239720409e-16

この方法でtransposeを上書きすると、 transpose([ :x _=1:4 ])が許可されるようです。つまり、私が投稿した内容です。 transpose / ctransposeを必要とするすべてのもの（たとえばQRCompactWYQ ）に正しく実装している限り、フォールバックが呼び出されることはないと思いました（より具体的な呼び出しのため）作ることができます）。

あなたのコードはあなたが書いたctransposeメソッドを呼び出していません（これは@which確認できます）。 Julia v0.5（v0.4には存在しません）で別のフォールバックメソッドを呼び出しています。これは基本的にctranspose(full(Q))ます。 この他のフォールバックは正しいですが、私たちがこの派手なQタイプを持っている理由そのものを打ち負かします（それで乗算を正確に行うことができます）。 フォールバックは正しいはずだという私のコメントはまだ残っています。

はい、すべての移調を正しく実装している限り、
もちろん、フォールバックは害を及ぼしません。 害はあなたがしないことです
それを忘れるとメソッドエラーは発生しませんが、黙って間違っています
結果。

クリックしてくれた@toivohに感謝します。 説明ありがとうございます。

しかし、フォールバックtranspose(X::AbstractMatrix)関数とtranspose(X::AbstractVector)関数を定義すると、おそらく常に正しい結果が得られます（たとえそれが遅くても...たとえばfullを呼び出す）いいえ？ そして、あなたはいつでもそれをより良く/より速くするためにもっと専門的な関数を書くことができます。 そうすれば、 transpose(::Any)は、前述の「駄洒落」以外のサイレントエラーを引き起こしてはなりません（つまり、 Complex数値を処理するとき...多分私が知らない他のスカラーユースケース？）

歴史的な理由からQRCompactWYQ <: AbstractMatrixですが、＃987＃10064によると、このサブタイプの関係は正しくないため、削除する必要があります。

行列のような非配列の別の例はIterativeSolvers.AbstractMatrixFcn 、これはAbstractMatrixサブタイプではありません。 このタイプの場合、参照するフォールバックがディスパッチされることはありません。これも私の主なポイントです。

このディスカッションはhttps://github.com/JuliaLang/julia/issues/13171で継続する必要があり

「チーム線形代数」の誰かがステップアップして、0.6でこれについて何かをすることにコミットする必要があります。そうしないと、再びぶつかります。

では、再起動するには、実際の計画は何ですか？

私の考え方は次のようになります： transpose(v::AbstractVector) = TransposedVector(v)ここでTransposedVector <: AbstractVector 。 TransposedVectorとAbstractVectorを区別する唯一のセマンティックな点は、 * （およびすべてのA_mul_B 、 \ 、 / 、...）。 つまり、 * （など）の下で契約するインデックスを決定するのはデコレータです。 転置は線形代数の概念であり、「データ」の配列を再配置する場合は、 reshapeとpermutedimsを推奨する必要があります。

TransposedVectorとAbstractVectorを区別する唯一のセマンティックなことは、 *下での動作です。

だからv'==vしかしv'*v != v*v' ？ これは理にかなっているかもしれませんが、混乱を招く可能性もあります。

だからv'==vしかしv'*v != v*v' ？ これは理にかなっているかもしれませんが、混乱を招く可能性もあります。

IMOこれは避けられません（おそらく不幸ですが）。

ベクトルの双対もベクトルです。 転置は、取得、変更、マッピング、削減などが可能な、明確に定義された要素を備えた1次元のデータ構造でもあります。

線形代数を配列から分離しない限り（たとえば、 Matrix{T}をArray{T,2}サブタイプと不変ラッパーの両方にし、より多くの（線形代数固有の）メソッドを定義する）、そこにあるかどうかはわかりません配列と線形代数の両方のプロパティと一致する多くの選択肢です。

（私にとって）1つの紛らわしい質問は、それがベクトルのようにブロードキャストするのか、それとも2番目の次元でブロードキャストするのかということです。 サイズが(1, n)場合、この変更全体は、最初の次元が長さ1ことがわかっている行列のように主張することを除いて、実際にはあまり効果がありません。 転置Vector{T}ままにする必要がありますArray{T,2} （つまり、 Matrix ...）、しかしそれの転置は可能性がVector （もう一度をたとえば、 v'' === vを使用できます）。

それはより良い考えですか？ それは壊れにくく、線形代数のセマンティクスを改善します。 編集： @martinholtersが表示するように==とは異なる動作をします）。

私には、 TransposedVector{T <: AbstractVector{Tv}} <: AbstractMatrix{Tv} *）とsize(::TransposedVector, 1)==1がありますが、 transpose(::TransposedVector{T})::Tは正直なアプローチのように聞こえますが、非常に多くの議論があり、おそらくこれに反対する良い議論がありますか？

*）これが構文的に無効であることは知っていますが、意図されたセマンティクスが明確であることを願っています。

はい、コードでアイデアを試してみると、@ martinholtersに同意します。

https://github.com/andyferris/TransposedVectors.jlから始めました

1つの大きな問題は、複素共役に対してCTransposedVectorタイプなしで生きることができるかどうか、またはそれが処理されるかどうかです。

個別のCTransposedVectorは使用しません。これは、2つの概念（共役と再形成）を1つのオブジェクトに結合するためです。 これらの2つの概念を別々のエンティティとして実装しておく方がはるかに構成可能です。 たとえば、MappedArrays.jlを使用すると、次のように簡単になります。

conjview(A) = mappedarray((conj,conj), A)

そして、あなたも素晴らしいパフォーマンスを得ることができます。

そうです、ティムに感謝します。 私はそのようなことを考えていました/期待していました-私の唯一の懸念は、2つのラッパーが常に「正しい」順序で表示されるようにする方法でしたが、これまでに実装したものでそれを処理できると思います。 また、これらすべての組み合わせに対してBLASをサポートする必要がありますが、これまで触れないようにできました。

1つの美しい点は、デフォルトでconjからconjviewに設定された個別の変更は、この変更とは無関係であるということです（両方とも独立したパッケージでいじくり回すことができ、正しく一緒に構成されると思います）。 conjをビューにする意欲はありますか？ インラインの非isbits不変がそのようなビューを無料にするのを待っていますか？ または待つ必要はありませんか？

@andyferris ：あなたのアプローチは良いものだと思います–それを前進させてくれてありがとう。 実装がうまく機能すれば、Baseでそのコードを使用できます。 覚えておくべきことの1つは、 https：//github.com/JuliaLang/julia/issues/5332にもTransposedMatrixが必要な場合があるということです

変換を続けたので、転置されたベクトル型を避けるように努めるべきであることをもう一度述べておきます。 上記で数回言及されていますが、この問題のすべてのコメントを誰もが再び読むことができるとは思えません。 ベクトルに転置型を導入すると、実際には複雑になり、ほとんどメリットがありません。 ベクトルに方向性があると本当に思っている場合は、それを行列にすると、うまくいきます。 行列とは異なる線形代数ベクトルを使用してから、新しいラッパータイプを導入して、ベクトルを1xn行列のように動作させることはあまり意味がありません。

現在の非対称性は、 x'がxを行列に昇格させるのに対し、 A*xはxを行列に昇格させないことです。 線形代数演算が2D専用の場合、 A*xはプロモートする必要があり、 x'xは1x1行列になります。 あるいは、ベクトルをベクトルにして、 A*xベクトルにすることもできますが、 x'はnoopまたはエラーになります。 転置ベクトルを導入するには、多くの新しいメソッド定義が必要になります。唯一の利点は、 x'xがスカラーになることです。

行列の転置は非常に異なっていると思います。 これにより、すべてのAx_mul_Bxメソッドを取り除くことができ、ベクトル転置の動作と同じように動作について議論することはできません。

TransposedVectorタイプを導入すると、TransposedMatrixタイプを導入するよりも多くの問題が発生することはよくわかりません。

はい、このオーパスの真ん中のどこかでの強いコンセンサスは、ベクトル転置が奇妙であり、それが実装された場合、それは間違いなくAbstractArrayサブタイプであってはならないということsize許可しません完全に上記の私のconjをマッピングするTimのアプローチを取ることをお勧めします）パラメータ）。

しかし、ベクトル転置が単にエラーであるというさらに強い要求がありました。 そうだとすれば、実際にはパッケージに収めることができると思います。

ベクトル転置をエラーにすることは、お風呂の水で赤ちゃんを捨てるようなものです。 ベクトルを転置するためにv'を記述できないことは、本当に、本当に面倒です。 ベクトルや行列との乗算方法を除けば、行行列のように動作するTransposedVectorタイプを使用することの何が悪いのかはわかりません。

これは、ベクトル転置で対処したい動作の数によって異なります。 単にv'' == v必要な場合は、 typeof(v') <: AbstractMatrixません。 しかし、 typeof(v'v) <: Scalarやtypeof(v'A) <: AbstractVectorように、このスレッドで説明した他のことをしたい場合は、別の、より複雑な獣である必要があります。

TransposedVectorを一種のVectorにするという考えは、多くの問題の根源にあるようです。 一種のマトリックスにして、今と同じようにsize(v.') == (1,length(v))を使用する方が、混乱がはるかに少ないようです。 唯一の違いは、二重転置がベクトルを返し、 v'vがスカラーを生成することです。 転置をベクトルとして扱いたい場合は、 length(v')が正しい答えを出し、線形インデックスが期待どおりに機能するため、可能です。

@StefanKarpinskiに110％同意します。 私はそれを一種のベクトルにすることをいじくりまわしましたが、このスレッドで前述したような理由から、あまり意味がなく、むしろ壊れています。

サイズを(1, n)するアプローチは、 Array動作に関して、現在とまったく同じように動作することを意味します。 1行N列のMatrixと区別する_only_操作は、 ' 、 .' 、 * 、 \ 。 および/ 。

それらはどれも「配列のような」演算子ではありません。 それらは純粋に行列とベクトルの間に線形代数を実装するためにあり、MATLAB（「行列ラボ」）から直接取得されます。 この最終的な改良は、 size(tvec, 1) = 1がコンパイラに対して静的にv''をvにしたいことを示しています。 （私は、一方の次元が固定され、もう一方の次元が動的にサイズ設定されるStaticArrayようなものだと思います）。

単にv '' == vが必要な場合は、typeof（v '）<：AbstractMatrixで問題ありません。

正しい。

しかし、typeof（v'v）<：Scalarまたはtypeof（v'A）<：AbstractVectorのように、このスレッドで説明した他のことを望む場合は、別の、より複雑な獣である必要があります。

どうして？ 配列のようなプロパティを壊していないので、それでも配列である可能性があります。 ドットコールは以前と同じように機能し、他のベクトル化された操作は削除されます。 *は、 VectorとMatrixのさまざまな形状の知識に「特化」していると思います。これは、記述された線形代数の動作をエミュレートしようとしているためです。 v' * vスカラーにすることは_非常に_標準的な数学であり、最初からそうではなかった唯一の理由は、一貫した方法で実装するのが簡単ではないためです（そしてジュリアが得たインスピレーションはMATLAB）、しかしステファンはそれを明確にすることができました。 内積をスカラーにすることは、ここで話す唯一の重大な変更です（他にも非常にマイナーなことがあります）-それだけでArrayになるのが不適切になる理由はわかりません（多くのタイプがあります）のArray有効ではありませんので' 、 .' 、 * 、 \と/ ALL_ _at定義されて、特にランク3+）

昨年私が遭遇した問題の1つは、あいまいさでした。 IIRCは、ベクトル転置が配列でない場合、解決がはるかに簡単でした。

はい、私はそれが終わる前にどれほど深くなるか少し心配しています... :)

一般的な注意として、 Baseモノリシックを減らし、それを標準ライブラリに分解すると、すばらしいでしょう。 AbstractArrayとArrayを定義するだけの自己完結型のパッケージまたはモジュールがあると、この種の開発が簡単になります。

@Juthoの提案の正確な問題は何でしたか？ *は、左側のベクトルを自動的に（共役）転置できません

*の行列乗算、 '行列（共役）転置（ベクトルを変更しない）、および末尾のシングルトンとdemoteを追加する2つの演算子promoteある場合末尾のシングルトンを削除するdemote 、右のアプリケーション*: (n,m) -> (m,) -> (n,) 、左のアプリケーション*: (n,) -> (n,m) -> (m,) 、内積*: (n,) -> (m,) -> (,) 、外積×: (n,) -> (m,) -> (n,m)そのような：

(*)(A::AbstractMatrix, v::AbstractVector) = demote(A*promote(v))
(*)(u::AbstractVector, A::AbstractMatrix) = demote((promote(u)'*A)')
(*)(u::AbstractVector, v::AbstractVector) = demote(demote(promote(u)'*promote(v)))
(×)(u::AbstractVector, v::AbstractVector) = promote(u)*promote(v)'

これらの演算子を使用してベクトルを転置する必要があるかどうかはわかりません。 私は何かが足りないのですか？

編集：正確には@Juthoの提案ではありません。

@Armavica 、この意味を*に割り当てるのが私の提案であるかどうかはよくわかりませんが、新しい（ユニコード）演算子∙に割り当てます。これは、現在dot相当します。 promoteとdemoteアプローチを型が安定した方法で実装できるとは思いません。

私の純粋主義者は、ベクトル自体の転置は避けるべきであるという@andreasnoackに同意します（私v'*wいつでもv'wまたはv'*wよりもdot(v,w)を書くことを個人的に好みます）が、私も感謝することができます@andyferrisによって提案された方法で機能させる

そう、@ Jutho。 興味深いことに、この2つは相互に排他的ではありません。デフォルトで定義されたベクトルに転置がないということは、この機能が別のパッケージ、モジュール、または「標準ライブラリ」に合法的に存在できることを意味します（つまり、「タイプの著作権侵害」はありません）。

（私はいつでもv'wまたはv '* wよりもdot（v、w）を書くことを個人的に好みます）

Jutho -一方で、私はあなたが書き込みをしません賭ける|ψ>⋅|ψ>紙またはオンしかし、ではなく、<ψホワイトボード|同じアナロジーが成り立つψ>（と私たちは内積を描画する方法テンソルネットワーク図付き）。

もちろん、私はディラックのブラケット記法を、すべての数学、さらには科学、ひいてはジュリアにおける線形代数の標準的な定式化として見たいと思っていますが、おそらくそれは起こらないでしょう。

今、あなたは私に余談を強要します、それは私がもうするつもりはありませんでした。 私は確かに内積に<ψ|ψ>を好むことに同意しますが、それは私が<ψ|を考えていないという事実とは無関係です。 |ψ>のエルミート共役として。 エルミート共役は、演算子に対して定義されています。 ベクトルとそれに関連する双対ベクトル（共ベクトル、線形汎関数など）の間の自然同形性は、リース表現定理として知られていますが、前者はもちろん、長さnベクトルを線形マップとして解釈するときのエルミート共役と同等です。 CからC ^ nまで、つまりサイズ(n,1)行列として。

もちろん、私はディラックのブラケット記法を、すべての数学、さらには科学、ひいてはジュリアにおける線形代数の標準的な定式化として見たいと思っていますが、おそらくそれは起こらないでしょう。

笑

今、あなたは私に余談を強要します、それは私がもうするつもりはありませんでした。

すみません...私は本当にそれについて言及するべきではありませんでした... :)

<ψ|は思いません |ψ>のエルミート共役として。 エルミート共役は、演算子に対して定義されています。

確かに、私はそれを考慮していませんでした。

ベクトルとそれに関連する双対ベクトル（共ベクトル、線形汎関数など）の間の自然同形性は、リース表現定理として知られていますが、前者はもちろん、長さnのベクトルをCからC ^への線形写像として解釈する場合のエルミート共役と同等です。 n、つまりサイズ（n、1）の行列として。

私は余談をしないようにしていますが（私はそれが苦手です）、 AbstractVectorを1D Array関連付けているので、この最後のビットを少し取得すると思います。 言い換えれば、 AbstractVectorは、数学的な意味での「抽象的なベクトル」を意味するのではなく、「事前定義された基準を持つベクトルの数値要素」を意味します。 ベクトルのサイズが(n,1)ため、MATLABはこれから簡単に抜け出しました。

思考の糧として、 |a>|b><c|形式のすべてのテンソルを取り、それらを|c><a|<b|マップする（反線形）演算子を何と呼びますか？ 私は常にこれを「エルミート共役」としてベクトル双対および標準演算子共役と一緒にバンドルしましたが、おそらくそれはあまりにも恥ずべきことです。

@alanedelmanと会話し、＃4774での私の立場についていくつかのことを

• CovectorまたはRowVectorタイプを導入します。
• 線形代数演算の場合（ * 、 ' 、 .' 、 / 、 \ 、多分norm ？その他？ ）このタイプは、線形代数の共ベクトルとして機能します。
• 配列操作（その他すべて）の場合、このタイプは2次元の1×n配列として機能します。
• 特に、コベクトルのsize(v')は(1, length(v))です。

このアプローチでは、Baseのすべてのジェネリック関数を線形代数として分類する必要があります。 特に、 sizeは配列関数であり、線形代数の定義域では意味がありません。線形代数は、基本的にベクトル（「形状」がなく、次元のカーディナリティのみ）、線形変換（たまたま2次元配列で表される場合があります）、およびスカラー。 思いついた1つの特定の例は、 cumsum 。これは、現在、1の次元引数が指定されているかのように2次元配列で動作します。 これはsumと矛盾します。これは、デフォルトで1の次元引数に設定されるのではなく、配列全体の合計を返します。 また、 cumsumが、ベクトルでの動作に対応する方法でコベクトルで動作するのを防ぎます。 cumsumは、N次元の列の主要な順序で累積的に合計することにより、一般的な配列で動作する必要があると思います。 より一般的には、ディメンション引数はデフォルトで1に設定されるべきではありません。

コベクトルを識別するためのインターフェースがない場合は少し心配です。 サイズやndimなどのほとんどの操作では、他の2次元または1次元配列とまったく同じであると言えます。 たとえばドット積を試すことによってのみ、違いがわかります。 AFAICTオブジェクトがRowVectorであるかどうかを確認する必要がありますが、特定の一般的なプロパティを持つためにオブジェクトに特定のタイプが必要になることは非常にまれです。

@StefanKarpinski私はそのすべてに同意します。 特に、その関数は「配列」演算または「線形代数」演算のいずれかです。

私はここでサイズ=（1、n） TransposedVectorから始めました。これはあなたが言うとおりです。 テストとすべての組み合わせ* 、 \ 、 /を、可能なcとtごとに適切にカバーするのに時間がかかりました。ベース内の他のメソッドとのあいまいさを回避しながら、メソッドと変更メソッド。 それは遅いですが体系的な作業であり、それから私は準備ができたときにそれをベースに引っ張ることができました（おそらく名前を変更する）。

それらはCovectorとの違いであり、実際には共役転置（または一般的な場合はさらに一般的な変換！）である必要がありますが、 RowVectorまたはTransposedVector概念的に単純です。

@JeffBezanson 「シングルトン」次元を持つためにindices()できることはありますか？

ただし、特定の一般的なプロパティを持つために、オブジェクトに特定のタイプが必要になることは非常にまれです。

そうです、これが特性か何かだったらクールでしょう。 より一般的に線形代数を配列から解きほぐすことができることを望んでいましたが、それは大きな変化です。 おそらく、Juliaに実装された優れた特性構文がなければ、きちんとしたものにはなりません。 ここでの問題は、3つのもの（ベクトル、コベクトル、行列）を2つのタイプ（ AbstractArray{1}とAbstractArray{2} ）にマッピングしているため、そのうちの1つ（コベクトル）が特別なサブタイプになることだと思います。他の。

基本的な「ラッパー」の実装以外のものが必要になる場所を考えられたら、 AbstractTransposedVectorをパッケージに入れていただろう。

@JeffBezanson ：私はあなたの心配をしません。 線形代数演算を除いて、1×n 2d抽象配列と同じように動作するという考え方です。線形代数演算では、列ベクトルの双対空間（1×n 2d抽象配列と同型）のように動作します。 コベクターをチェックしたい場合は、例えばディスパッチすることでタイプをチェックできます。

これに取り組む私の試みに関する最新情報：

TransposedVectors.jlは、「機能が完了した」と私は信じています。 これには、 @ StefanKarpinskiがここで述べたことを実行するために必要なすべての機構が含まれています-ベクトルの転置は、2次元の1xnサイズの抽象配列として動作するベクトルのラッパーです-ただし、線形代数演算（ * 、 / 、 \ 、 ' 、 .' 、 norm ）、行ベクトル（またはデュアルベクトル）として動作します。

あなたはそのようにそれをチェックすることができます：

julia> Pkg.clone("https://github.com/andyferris/TransposedVectors.jl")
...

julia> using TransposedVectors
WARNING: Method definition transpose(AbstractArray{T<:Any, 1}) in module Base at arraymath.jl:416 overwritten in module TransposedVectors at /home/ferris/.julia/v0.5/TransposedVectors/src/TransposedVector.jl:28.
WARNING: Method definition ctranspose(AbstractArray{#T<:Any, 1}) in module Base at arraymath.jl:417 overwritten in module TransposedVectors at /home/ferris/.julia/v0.5/TransposedVectors/src/TransposedVector.jl:29.
WARNING: Method definition *(AbstractArray{T<:Any, 1}, AbstractArray{T<:Any, 2}) in module LinAlg at linalg/matmul.jl:86 overwritten in module TransposedVectors at /home/ferris/.julia/v0.5/TransposedVectors/src/mul.jl:9.
WARNING: Method definition At_mul_B(AbstractArray{#T<:Real, 1}, AbstractArray{#T<:Real, 1}) in module LinAlg at linalg/matmul.jl:74 overwritten in module TransposedVectors at /home/ferris/.julia/v0.5/TransposedVectors/src/mul.jl:37.
WARNING: Method definition Ac_mul_B(AbstractArray{T<:Any, 1}, AbstractArray{T<:Any, 1}) in module LinAlg at linalg/matmul.jl:73 overwritten in module TransposedVectors at /home/ferris/.julia/v0.5/TransposedVectors/src/mul.jl:64.

julia> v = [1,2,3]
3-element Array{Int64,1}:
 1
 2
 3

julia> vt = v'
1×3 TransposedVectors.TransposedVector{Int64,Array{Int64,1}}:
 1  2  3

julia> vt*v
14

julia> vt*eye(3)
1×3 TransposedVectors.TransposedVector{Float64,Array{Float64,1}}:
 1.0  2.0  3.0

パフォーマンスが低下する可能性があります。ベンチマークが役立つでしょう。 コピーが少なくなる場合（転置が怠惰な場合）もあれば、コピーが多くなる場合もあります（たとえば、ベクトルの共役コピー（行列ではない）がAc_mul_Bcで作成される場合があります）。 そして、ラッパー自体は、不変の可変フィールドをインライン化するまでわずかなコストがかかります（幸いなことに、これはStaticArrays.jl ：smile：ですでにうまく機能しています）。 必要に応じて、ある種のStridedArrayであることを確認するという問題もあります。

このアプローチが好きな人は、すぐにPRを作成してコードをBaseに移行することを確認できます（パッケージにはすでに単体テストがあり、すべてのあいまいさが解決されています）。 （また、 @ jiahaoは、デュアルベクトルの1次元抽象配列バージョンを実験したいと述べていましたが、進展があったかどうかは

転置行列のラッパー型がなければ、そのようなPRはv0.6で意味があると人々は思いますか？ 転置されたベクトルは意味の変化ですが、転置された行列はより最適化されているので、別々に入れることができると思います。 もちろん、いくつかの転置がビューであり、いくつかがコピーである場合、それは「奇妙」に見えるかもしれません-意見？ 考慮すべきもう1つのポイントは、転置された行列とベクトルの両方が含まれると、すべてのAt_mul_Bt関数を削除し、 *メソッドに置き換えて、を完了するために多くの作業を行う必要があるということです。移行（単純化はやりがいがありますが！）-今月末までに誰もがそのすべてを実行できる、または実行する意思があるとは思えません...

素晴らしい仕事、@ andyferris！ 一般的な怠惰なConjugateラッパーを試してみましたか？

@andyferris私はタイヤを蹴った、そしてこれがかなり好きだ。 厳密には改善のようですが、パフォーマンスの問題が見つかったときに処理できることを望んでいます。 他の人が何を言わなければならないか見てみましょう。

みんなありがとう ：）

一般的な怠惰なConjugateラッパーを試してみましたか？

まだ、手間をかけなくてもできるかもしれませんが、正直、12月末までにこんなに終わらないのではないかと心配でした。 将来を見据えて、私は最終的に、線形代数のためにディスパッチする次の「unionall」タイプがあるかもしれないと考えていました。

• AbstractVector
• Conjugate{V where V <: AbstractVector} （またはConj{V} 、おそらくConjArray ？もちろん、任意の次元の配列を受け入れます）
• TransposedVector （またはRowVector ？）
• TransposedVector{Conjugate{V where V <: AbstractVector}}
• AbstractMatrix
• Conjugate{M where M <: AbstractMatrix}
• TransposedMatrix （または単にTranspose{M} ？）
• TransposedMatrix{Conjugate{M where M<:AbstractMatrix}}

（さらに、現在DenseArrayやStridedArrayと呼んでいるものなど、基盤となるストレージのすべての特定の特性-＃18457によってこれらも少し簡単に表現できるようになることを願っています）。

名前を付けることは別として、それは合理的な計画のように聞こえますか？

即時のバイクシェディングに関しては、現在パッケージに含まれているもののベースへのPRとして、ベクトルと行列の両方に汎用のTransposeラッパーであるTransposedVector 、 RowVectorを優先しますか？ 、 または、他の何か？

@andyferrisの実装によって提供される動作はかなり良く、改善されていると思います。 しかし、私の懸念をもう少しよく表現しようと思います。

問題は、新しい配列タイプの定義にあります。 たとえば、 DArrayはAbstractArrayサブタイプであるため、 DArrayはAbstractVectorまたはAbstractMatrixすることもできます。 理想的には、ベクトル/マトリックスの区別を行/列/マトリックスに拡張するだけなので、 DArrayはAbstractRow 、 AbstractCol 、またはAbstractMatrix 。 タイプ階層は次のようになります

AbstractArray
    AbstractVector
        AbstractRowVector
        AbstractColumnVector
    AbstractMatrix
    ...

昨日これについて@jiahaoと話してい

ここでは、すべてのAbstractVectorを列として使用できるわけではないという点で、いくつかの優先順位がある場合があります。例：

julia> isa(1.0:10.0, AbstractVector)
true

julia> randn(10,10) * 1.0:10.0
ERROR: MethodError: no method matching colon(::Array{Float64,2}, ::Float64)

https://github.com/JuliaLang/julia/issues/4774#issuecomment-59428215で私が抱えていた問題に対処できます

それは範囲の周りに括弧がないだけですか？

これは単なる優先順位の問題です。

julia> randn(10,10) * (1.0:10.0)
10-element Array{Float64,1}:
 -22.4311
  ⋮

ここでの最適な解決策には特性が必要であるように思われることに同意しますが、それが@andyferrisの作業を

ああ、良い点。 Fortressと同様に、空白の優先順位が正しくない場合は構文エラーになります。

MITグループは、上記で説明した型階層を実装する1つの方法は、配列階層に型パラメーターを追加することであると指摘しました。

abstract AbstractArray{T,N,row}

type Array{T,N,row} <: AbstractArray{T,N,row}
end

typealias AbstractVector{T} AbstractArray{T,1}
typealias AbstractRowVector{T} AbstractArray{T,1,true}
typealias AbstractColVector{T} AbstractArray{T,1,false}
typealias AbstractMatrix{T} AbstractMatrix{T,2}

typealias Vector{T} Array{T,1,false}
typealias Matrix{T} Array{T,2,false}

私はこれのすべての意味を理解していません---おそらく最悪のことはArray{Int,1}が抽象型になることです---しかしこれは型階層と必要な抽象化をほぼ正確に取得しているようです。

価値があるのは、これは完全にパラメーター化されていないスーパータイプのユースケースです。 それらは暗黙のデフォルトパラメータになる可能性があります。

abstract AbstractArray{T,N,row}

type Array{T,N} <: AbstractArray{T,N}
end

isrow{T,N,row}(::AbstractArray{T,N,row}) = row
isrow{T,N}(::AbstractArray{T,N}) = false

julia> isrow(Array{Int,2}())
false

もちろん、それはディスパッチを少し厄介にします…そしてそれはサポートする価値がないかもしれません。 それはただの唾球です。

私にはそれは定義することと同等のようです

type Array{T,N} <: AbstractArray{T,N,false}
end

ここで必要になるのは、ある種の「デフォルトの型パラメータ」です。たとえば、XとYに自由変数がない型Array{X,Y}を作成すると、実際にはArray{X,Y,false}ます。

別のアイデア：内積v'vハウスホルダー表記を保持し、左の共ベクトルは、これらをv'*vおよびv'*Aとして解析する代わりに、中置'を独自の演算子にすることにより、 v'A乗算しますv'*A 。 v' ID、 v*vをエラー、 v*Aをエラーにすることと相まって、これは望ましいものの多くを与える可能性があります。 外積をouter(v,v)と書く必要があります。

このようなスキームでは、 v'はnoopまたはエラーにさえなります。このようなスキームではベクトルを転置する理由がないため、行列に対してのみ意味があります。

@JeffBezanson AbstractRowVectorが最適であることに同意します（ただし、正直なところ、ユースケースを考えることができないため、パッケージに実装しませんでした）。 これはAbstractMatrixサブタイプとして生きることができることも指摘したいと思います。 私がこの方向に進んだ理由は、 broadcastが線形代数よりもジュリアのコアコンセプトであるように思われ、人々は行ベクトルが行であると期待するからです。

もちろん、 RowVector <: AbstractMatrix使用することは、残念ながら用語の使用です。 これは、2D配列と抽象行列に同じ名前が付けられているためだと思います。

これは前にも言いましたが、この問題は非常に長いので、言い換えます。Juliaのようなジェネリック言語では、「データの配列」プロパティをAbstractArray主な考慮事項にする必要があります。 broadcastをどのように動作させるかを答えると、それが1Dか2Dかがわかります。 行と列の観点から考えたい場合は、 1 x n行ベクトルが最も理にかなっています。 双対ベクトルを検討したい場合は、1Dが最も理にかなっています-そして私もそれに満足しています！ ただし、ベクトルの双対を取ることは、データを再形成するよりも複雑です（たとえば、少なくとも活用をサポートする必要があります）。

「行」の図は「典型的な」プログラマーの期待に一致すると思いますが、高度な数学のトレーニングを受けた人は、より優れた抽象化であるため、双対ベクトルをより有効に活用できる可能性があります（ただし、基本的な線形代数の知識しかない人に同情する）。 では、ジュリアはどのオーディエンスをターゲットにしていますか？多くの典型的なMATLABユーザーよりも数学的な精巧さを持っている人、または少ない人ですか？

（私の考えでは、ジュリアは「ジェネリック」プログラミング言語を目指していたので、後者の聴衆がターゲットでした）。

可能なタイプツリーについて議論しているので、将来的にはBufferとサイズ変更可能な「リスト」を使用して、次のようなものに沿ったインターフェイスの抽象的なツリーを想像しています。

AbstractArray{T,N} # interface includes broadcast, Cartesian, getindex, setindex!, etc.
    AbstractArray{T,1}
        AbstractList{T} # resizeable, overloaded with `push!` and so-on
        AbstractVector{T} # non-resizeable, overloaded for *, /, \, ', .', etc
    AbstractArray{T,2}
        AbstractRowVector{T} # non-resizeable, overloaded for *, /, \, ', .', etc
        AbstractMatrix{T} # non-resizeable, overloaded for *, /, \, ', .', etc

もちろん、 AbstractDualVector{T} <: AbstractArray{T,1}代わりにAbstractRowVector AbstractDualVector{T} <: AbstractArray{T,1}を使用することもできます。

これらすべてに適合する柔軟で具体的なArrayタイプを使用することは困難です（おそらく不要です）。 特性により、サポートされているインターフェイスでこれらの違いをより簡単に表現できるようになります。

AbstractVectorがC ++ std::vectorと線形代数ベクトルの両方であるということは、私には少し生意気なように思えました：）（特に、配列インターフェイスは、それが本当に「抽象的なベクトル」になることは決してないことを意味します。線形代数センス（例：基底なし））

はい、サイズ変更の動作を分離するとよいでしょう。 私はそのために乗り込んでいます。

その型階層は、Baseに別々の「行列」と「2次元配列」の具象型があることを意味しているようです。 たとえば、 Array{T,2}のコンストラクターが実際に他の行列タイプを返すようにすることで、それを回避しようとすることができますが、かなり醜いようです。 多分私は誤解しています。

その型階層は、Baseに別々の「行列」と「2次元配列」の具象型があることを意味しているようです。

そうです...これをうまくやるには、特性が必要だと思います。 私はそれを「インターフェースの抽象的なツリー」と呼んだことを覚えておいてください。 現時点でこれを試みると、あなたが言ったように醜い何かが必要になります。 しかし、 Bufferが完了するとすぐに、おそらくAbstractList <: AbstractVector挿入（および関連するメソッドを移動）することができます。

現時点では、サポートされているインターフェイスとタイプツリー間の接続はかなり緩いです。 （抽象）配列が可変であるか（つまり、 setindex!サポートするか）、サイズ変更可能であるか、stridedがBaseで定義された型でのみ機能するかなど、ディスパッチ時に判断するのは困難です。ユーザーが機能し、幅広い入力で効率的なメソッドを提供するのは難しいです（これはStaticArraysからの私の経験です）。

タイプ階層のマシー領域とパラメーター化された抽象化の合理的な役割についての会話についての考え。 達成可能な場合、Juliaは、専門家が意図することと専門家が表現する意図を実行するためのコードの記述方法の分離を簡素化および軽減することをお勧めします。

私たちが使用することを選択する可能性のある1つの規則は、Any以外の抽象型を使用して、付随する具象型が共有された休息を容易にする中で、オントポロジー領域を形成する一般的な方法です。 これにより、非常に少ないコストで、マルチコンテキストの感覚が向上します。型階層のある部分を理解すると、他の部分にアプローチするのに役立ちます。

私がこれを見ると、それは一般化された信頼関係をもたらすものです。 解明的な抽象化は、構成する生成的な類似性である、具体的な一致を示す近隣として光ります。 直感の単純な明快さを運ぶパラメーター化により、ジュリアはより少ないナンセンスな時間で多くのことを達成します。

OK、 TransposedVectorsに関するコメントをいただければ幸いです。 かなりしっかりしていて、PRに変える準備ができていると思いますが、ここにリストしたいくつかの関連する問題があり

（例： RowVectorはTransposedVectorよりも良い名前ですか？ [1 2 3]はRowVectorまたはMatrixですか？ indices(row, 1)とは何ですか

RowVectorの+1

2016年12月20日午前7:01、「AndyFerris」 [email protected]は次のように書いています。

OK、 TransposedVectorsに関するコメントをいただければ幸いです。 感じます
それはかなり堅実になり、PRに変える準備ができていますが、
私がここにリストしたいくつかの関連する問題
https://github.com/andyferris/TransposedVectors.jl/issues 。

（例：RowVectorはTransposedVectorよりも優れた名前ですか？[1 2
3] RowVectorまたはMatrix？ インデックス（行、1）とは何ですか？）

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/4774#issuecomment-268170323 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAm20YYqsXmprI23GgI5PYyWStpTOq5qks5rJ309gaJpZM4BMOXs
。

行/列の規則を避けたいのですが、 VectorとRowVector （またはColVectorとRowVectorがあるのは奇妙に聞こえると思います。 TransposedVectorまたはDualVector場合

@felixrehren DualVectorは、私が実装したものとは異なるセマンティクスを持つ必要があると感じています。主に1次元であり（数学的には、ベクトルの双対はベクトルです）、他の双対特性（複素共役など）があります。 。 これは問題ありませんが、実装が少し難しく、下位互換性が少し低いことがわかりました。

TransposedVectorという名前は大丈夫です。 しかし、それは少し長いです。 また、そのタイプのオブジェクトは、 Vector転置することによってのみ取得できることを示唆しています。 しかし、他の方法でも、たとえば行列の1行を抽出することで、 TransposedVector作成できると思いますか？

RowVectorは良い名前だと思います。簡潔で、正確で、直感的です。 @felixrehren 、行/列の画像が役立つと思います。 連結やその他の一般的な配列操作（乗算以外）を行うときは常に、ベクトルがどちらの方向を向いているかを考える必要があるため、おそらく避けられないことです。

DualVectorも悪くはありませんが、 CoVectorは形式的ではないように聞こえます。

私が以前に脅したPRは現在＃19670で提出されています。 今のところRowVector行きました。

しかし、他の方法でも、たとえば行列の1行を抽出することで、TransposedVectorを作成できると思いますか？

これは実際には1つのこだわりのポイントです-私はまだそのための優れた構文を考えていません。 何か案は？

しかし、他の方法でも、たとえば行列の1行を抽出することで、TransposedVectorを作成できると思いますか？

これは実際には1つのこだわりのポイントです-私はまだそのための優れた構文を考えていません。 何か案は？

最初は、 matrix[scalar,range] （および他の同様の構造）が行ベクトルを生成することは魅力的であるように見えましたが、これは多次元配列の現在のインデックス作成セマンティクスからの大幅な逸脱であり、特別な場合は私を不安にさせます。

代わりに、 RowVector （さらに言えばVector ）が反復可能な型を適切な種類のベクトルに変換することを望んでいます。 次に、 RowVector(matrix[scalar,range])ようなことを行うことができます。これは非常に明確で、配列のインデックス作成の現在の動作を妨げることはありません。

そうです、 i番目の行はA[i,:].'によって行の形で抽出できますが、現在はv0.5であり、今後もそうし続けます（ RowVectorを作成するため） Transpose{V<:AbstractVector}または最終的に決定するもの（進行中の議論についてはここを参照））。 多分それが答えです。

Baseに2つの新しい関数を追加するのはどうですか？
row(A,i)およびcol(A,i)
後者は必要ありませんが、対称性のためだけです。 簡潔で明確、そしてA[i,:].'と同じ数の文字です

理にかなっているVectorとRowVector一緒に使用するのは好きではありません。

この時点で、 @ andyferrisの実装に基づいたものを使用するか、ベクトル転置を真剣に受け止めないことを決定する必要があると思います。 別の方法の例として、最悪の症状を処理するアプローチを次に示します。 v'を現在のままにします（つまり、行行列を生成します）が、 a'bを中置演算子として解析します。乗算。 つまり、次のような動作になります。

1. v'は行行列（ctranspose）です
2. v'vはスカラー（内積）です
3. v'*vは1要素のベクトル（行行列*ベクトル）です
4. v*v'は外積行列（ベクトル*行行列）です
5. v'Aは行行列（ "vecmat"）です
6. v'*Aは行行列（matmat）です
7. v'A*vはスカラーです（matvec A * v、次にドット積）
8. (v'A)*vは1要素のベクトルです（vecmat、次にmatvec）
9. v'*A*vは1要素のベクトルです（matmat、次にmatvec）
10. v''は列行列です（ベクトルctranspose、次に行列ctranspose）

現在のセットアップでは、2と3は同等であり、7、8、9は同等であり、この変更は機能しません。 しかし、決定的に重要なのは、大胆なアイテムは、類似したフォームの中で最も短く、最も便利であるため、人々が一般的に到達するアイテムです。 新しいタイプはなく、1つの新しい中置演算子だけです。 主な欠点は10です– v''はまだ列行列です。 おそらく、接尾辞''はベクトルを列行列に変換するための演算子であるため、これは利点と見なすことができます。

一歩後退して、私たちが学んだことは、追加の上下または次元のラベル付け機能がなければ、またはMatlabのように2次元以下を代替可能として扱うことなしに、多次元配列を線形代数とスムーズにアリ溝にすることはできないということです。 ですから、私たちに残されているのは利便性の問題です。配列を過度に複雑にすることなく、ベクトルや行列に対する一般的な線形代数演算を便利に表現できるでしょうか。 私はこのアプローチに完全に固執しているわけではありませんが、配列型の階層をあまり乱さずに構文上の利便性に対処するこのアプローチや他のアプローチを真剣に検討する必要があると思います。

別のアプローチは、中置辞a'b特別に（ *すぐ下で）解析し、 v'共役ベクトルを返すことです。 より一般的には、接尾辞A'は配列を活用してその次元を怠惰に逆転させることができますが、 A.'は配列の次元を怠惰に逆転させ、ベクトルのアイデンティティとして機能します。 このスキームでは、プロパティのリストは次のようになります。

1. v'はベクトル（共役）です
2. v'vはスカラー（内積）です
3. v'*vはエラーです（内積にはv'v 、外積にはouter(v,v)をお勧めします）†
4. v*v'はエラーです（内積にはv'v 、外積にはouter(v,v)をお勧めします）†
5. v'Aはベクトル（vecmat）です
6. v'*Aはエラーです（vecmatにはv'Aをお勧めします）
7. v'A*vはスカラーです（matvec A * v、次にドット積）
8. (v'A)*vはエラーです（内積にはv'v 、外積にはouter(v,v)をお勧めします）†
9. v'A'vはスカラーです（ v'(A'v) –共役matvec、次に内積）
10. v''はベクトルです（ v'' === vおよびv.' === v ）

これらのプロパティをすべて書き出すので、これが望ましいオプションかもしれません。すべてのエラーケースは、実際には、人々が適切な構文を見つけて使用するのに役立ちます。もちろん、望ましいv'' === vプロパティがあります（そしてうまくダブテールします）。 .'は一般的な次元反転演算子です）。 わずかに異なるだけの非常に類似した構文を持つことは、おそらくもっと混乱します。

†これらの操作が機能するようにユーザーコードが'と*をオーバーロードした場合にエラーが発生するリスクがありますが、解析時にこれらをキャッチしてより正確なエラーを検出できる可能性があります。 これらの推奨事項を正しくするには、怠惰な活用ラッパーが必要になると思いますが、とにかく＃5332ではそれが必要です。

一歩後退して、私たちが学んだことは、追加の上下または次元のラベル付け機能がなければ、またはMatlabのように2次元以下を代替可能として扱うことなしに、多次元配列を線形代数とスムーズにアリ溝にすることはできないということです。 ですから、私たちに残されているのは利便性の問題です。配列を過度に複雑にすることなく、ベクトルや行列に対する一般的な線形代数演算を便利に表現できるでしょうか。 私はこのアプローチに完全に固執しているわけではありませんが、配列型の階層をあまり乱さずに構文上の利便性に対処するこのアプローチや他のアプローチを真剣に検討する必要があると思います。

：100：

後置'および.'ジェネリック配列（線形代数ではなく）操作を明示的に行うことで、ストレージと線形代数のタイプの混同を2倍にすることをうまく回避し、妥協の少ないフレームワークへの扉を開いたままにします。 暫定的に、最も一般的なケースでハウスホルダー表記をシミュレートするこれらの操作の機能は、望ましい利便性のほとんどを提供するはずです。 また、コードと複雑さが軽減されます。 ベスト！

v.'がノーオペレーションである場合の1つの問題は、 A .+ v.'がA各列にvの値を追加することから、値を追加することへと意味が変わることです。 Aの行に。 これは一般に、ベクトルを使用して行のような操作を行うのを難しくし、コードが間違ったことを黙って行わないようにするために完全な非推奨サイクルが確実に必要になります（このような場合、 Aがたまたま正方形になります）。

この時点で、 @ andyferrisの実装に基づいたものを使用するか、ベクトル転置を真剣に受け止めないことを決定する必要があると思います。

v0.6の締め切りが迫っていることは承知していますが、お風呂の水で赤ちゃんを捨てないように注意します。 この段階では、前述のRowVector加えて、行列の転置と配列の活用のビューにより、次のことが可能になるようです。

• IMO、やや合理的な線形代数タイプ（行ベクトルは双対ベクトルの特殊なケースと見なされる可能性がありますが、現在のように双対ベクトルの存在を否定していません）
• v'' === v
• v1'v2ようなStefanのリストにあるもののいくつかはドット積です
• ほぼ下位互換性のある配列セマンティクス-たとえば、 size(v')は変更されませんが、1次元としてv''ます
• 怠惰な接続詞と転置ラッパーは、特定の状況でパフォーマンスを向上させ、とにかく役立つ可能性があります
• *とA_mul_B!のみを優先してすべてのAc_mul_Bc関数を削除します（同様に\ 、 / ）。

これらすべてをArray正直に機能させるのに、それほど労力はかかりません（私にとって問題は、この時期に時間を見つけ、線形代数スイートにある他のすべてのタイプを追跡することです）。 そして最後のポイントは安堵のため息です。

反対に、私見では、これらのルールは構文解析を少し複雑にしているようで、 'と*どのように構成するかについて少し混乱したり驚くかもしれません（3、4、6、8はRowVector ）。

そして、はい、潜在的なバグを強調するためにv.'か何かを非推奨にする必要があります。その時点で、 v.'を欠落したメソッドエラーにする方がほぼ良いようです（単に行をサポートしません） / dual vector、ただし必要に応じてパッケージの停止は停止しません）

19670は、v0.6に何かを忍び込ませたいという欲求がある場合、準備ができているか、それに近いものを探しています。

BAM

うわー。

これは私たちの最長の問題のスレッドでしたか？

いいえ、＃11004にはもっとあります

ごめんなさい。 そうです、私は未解決の問題のスレッドを指定