Julia: ベースの内積の状態

ユースケースについてもう少し説明していただけますか。また、パッケージで定義するだけでなく、Baseで使用することが有益な理由を教えてください。 具体的な例が最適です。 同時にロードされたパッケージ全体でいくつかのinner定義を期待しますか？

これらの数学的空間のための正式なインターフェースを持つことは、ユーザーが型システムをよりよく活用するのに役立つと思います。 たとえば、クラスタリング手法はどの距離空間でも機能すると思います。 内積で型を定義できれば、（パッケージがそれに応じて修正された後）箱から出してClustering.jlの恩恵を受けるでしょう。 他の多くの距離ベースまたは投影ベースのアルゴリズムも一般化できます。

具体的な例として、今日、構成データのジオメトリを定義しようとして、この制限に遭遇しました。https ://github.com/juliohm/CoDa.jlよく知られているinner関数に特化したいと思います。他の誰も気付かない自分のインターフェースを定義するよりもBaseで定義されています。

ヒルベルト空間タイプのdotを拡張してみませんか？ 一般的な内積を念頭に置いて設計されていると確信しています。

内積の概念は、内積の概念よりも厳密です。 後者は一般的なスペースに対して定義されますが、内積は、有限基底によって定義される座標系の概念がある場合にのみ定義されます。 dot(x,y)のセマンティクスはx'*yです。ここで、 xとyは、デカルト世界のオブジェクトの座標を表します。 数学の教科書では、ドット積という用語について言及することはめったにありません。著者は通常、より一般的な（必ずしも有限でもユークリッドでもない）空間で材料を扱うことに関心があるからです。

さらに区別するために、内積<x,y> （またはinner(x,y) ）を持つヒルベルト空間では、オブジェクトは無限である可能性があり、セマンティクスx'*yは適用されません。 たとえば、関数データ分析では、オブジェクトは関数fとgであり、内積は通常、数値積分によって取得されます： inner(f,g) = quadrature(f*g) 。 この操作をドット積と呼ぶのは誤解を招く恐れがあります。

CoDa.jlパッケージで指摘したもう1つの例は、構成データです。 コンポジションオブジェクトは、操作x'*yが意味をなさないシンプレックスの世界にあります。 ただし、等角変換（対数比変換）が存在します。これを使用して、構成を別のジオメトリにマッピングし、座標を使用して内積を適用できます。 座標を操作する必要はありませんが、この分野では一般的な方法です。 結果は、オブジェクトが存在する元のスペースに逆変換できます。

言語でdotという用語を維持することにメリットはありませんが、下位互換性を求める場合は、一般化inner(x::AbstractVector, y::AbstractVector) = dot(x,y)は完全に機能します。

この変更に対する異議について詳しく説明していただけますか？

この変更に対する異議について詳しく説明していただけますか？

Baseに新しいパブリック関数を追加するには、通常、かなりの正当性が必要です。これは異論です。 これは、 InnerProductsパッケージによって提供される可能性があります。 なぜそれを言語自体に組み込む必要があるのですか？ これは、 @ andreasnoackが上記で尋ねた最初の質問でした。「これらの数学空間の正式なインターフェイスがあると、ユーザーが型システムをより有効に活用できるようになると思います」というやや漠然とした答えが得られました。 パッケージで定義されたインターフェースがBaseのインターフェースよりも形式的でない理由はありません。 Base.innerを持っていると、 InnerProducts.innerが提供しないものは何ですか？ これは説得力のある答えが得られる本物の質問ですが、その答えが何であるかはわかりません。そのため、質問が行われています。

Baseにない他の場所の内積のような基本的な数学的概念を定義するための良い議論は見当たりません。 主な対象者が科学計算の人々である言語は、正しい用語の恩恵を受けるでしょう。 norm Base.LinAlg定義されており、同じコホートにあるinnerをパッケージで定義する必要があるのはなぜですか？ この矛盾に加えて、言語にはすでにdotがあります。これにより、より一般的な概念ではなく、なぜこれほど具体的なものが必要なのか疑問に思います。

それで、あなたは基本言語で可能なすべての数学的概念が欲しいですか？ Baseで何かが定義されていなくても、人々が間違った用語を使用することを強制されることはありません。 norm関数は、 LinAlgで定義および使用されているため、 LinAlgからエクスポートされます。 dotについても同様です。 dotの名前をinnerに変更することを提案していますか？

それで、あなたは基本言語で可能なすべての数学的概念が欲しいですか？

私はそれは決して言ってない。

Baseで何かが定義されていなくても、人々が間違った用語を使用することを強制されることはありません。

そうではないと確信しています。 間違った用語を宣伝することが問題です。 数学的な背景が少ない人は、Baseで表示されるため、ドットの使用法を採用します。 内積の概念を表すための「ドット」積という用語の使用は正しくありません。 また、間違った用語が残したこれらの傷跡を修正するのに時々苦労している数学コミュニティにとっても有害です。 私の世代の学生は、用語を正しく理解するために常に古い本を参照する必要がありますが、そうではないはずです。

ドットの名前をinnerに変更することを提案していますか

それは私の意見ではすでに大きな改善になるでしょう。 機能データと構成データについては、上記のすべての例を参照してください。 これらのコミュニティの人々は、仕事でdotという用語を使用することは決してありません。 「ドット」は、何よりもコンピュータサイエンスの用語に似ています。

dotの名前を$＃ innerに変更することは、 dotに加えてinnerをBaseに追加することとはまったく異なる提案です。 これは「正しい用語」の質問であり、あなたや他のlinalgの人々はハッシュ化する必要がありますが、これを一度バイクシェッドして、 dotがこの関数の実装の正しい名前であると結論付けたのを思い出しているようです。

https://github.com/JuliaLang/julia/issues/22227とhttps://github.com/JuliaLang/julia/pull/22220でこれについて少し議論がありました

ドットの名前をinnerに変更することは、dotに加えてinnerをBaseに追加することとはまったく異なる提案です。

これは、このスレッドの最初のメッセージで提案したものです。

ドットの名前をinnerに変更するか、inner（x、y）をオブジェクトxとyの間の一般的な内積として定義するようにユーザーに指示することを提案したいと思います。

繰り返しますが、ドット積は、ここで説明している操作の誤った用語です。 内側、外側、内積...これらは数学的対象です。 「内積」は計算オブジェクトです。2つの数値シーケンスを取得し、 x1*y1 + x2*y2 + ... xn*ynを実行します。これは、他の数学空間では役に立たない操作です。

私はあなたが提案した2番目のオプションに焦点を合わせていました。それはBase.dotを呼び出すためのフォールバックでBase.innerを追加していたようです。 どちらのオプションも可能ですが、どちらも正当な理由が必要です。新しい操作を追加するには、パッケージに含めることができない理由が必要です（この説明の最初の部分について）。 名前を変更するには、 dotが間違った名前であり、 innerが正しい名前であると判断する必要があります（会話が変わったように見えます）。

@juliohm現在、 Baseを縮小し、パッケージの使用を奨励しようとしている積極的な取り組みがあることを（再）述べる価値があります。 この場合、 dotは、標準のJuliaで提供される線形代数に参加するすべてのタイプ（つまり、 NumberとArray ）に対して正しいようです。したがって、確かに、既知の、すべての場合に有限の基礎-したがって、より良い選択があるかもしれませんが、用語を間違えたとは思いません）。 私はこの提案に反対していませんが、変更に対する「潜在的な」抵抗を経験している理由を明確にするために、これを指摘したいと思います。

また、かなりの数のJuliaの新参者は、内積には精通しているが内積には精通していない可能性があることを覚えておく価値があります（たとえば、大学で少し物理学を学んだが、数学専攻ではない）。 dotを保持します（対応する中置演算子があることは言うまでもありません- innerにマップすることもできますが、それは少しわかりにくいです）。 また、 outer関数、またはその他のさまざまな可能な操作はありません。

したがって、これをユーザーパッケージに入れるよりも、これをBase （またはLinAlg ）に入れる方が厳密に優れているという合理的なケースを作成するのは負担があります。 主な理由は、他の人が共有および拡張できるインターフェースを提供することであるように思われます-それは合理的な要約ですか？ Clustering.jlのジェネリックコードを内積で動作させることについての議論は、かなり説得力があるようです。 また、 LinAlgをstdlibパッケージに分割しているように見える状況では、 LinearAlgebraというパッケージを作成する場合は、おそらくinnerを含めてよかったと思っていました。他の人が拡張するための

あなたの考えを共有してくれてありがとう@andyferris 。 抵抗がはっきりと見えますが、あまり興奮していません。 それにもかかわらず、私はこの特定の提案がどのようにコードの増加につながるのか興味がありますか？ 私には、抽象化が大幅に改善された、コードの些細な変更のように思えます。 Clustering.jlの例は、多くの例の1つにすぎません。内積の概念が存在する、任意のJuliaタイプで機能するように作成できるカーネルベースのメソッドを考えてみてください。 MultivariateStats.jlにはたくさんあります。

LinAlgを別のパッケージに分割することについてのコメントに関しては、数学製品をカプセル化するのに適した場所のように思われることに同意します。 この将来のLinearAlgebraパッケージは、デフォルトでJuliaセッションにインポートされるため、すべてのユーザーがinner 、 outerなどの概念にアクセスできると想定しています。すぐに。

はい、標準ライブラリはすべてJuliaシステムイメージと一緒に構築されており、デフォルトで利用できます。 少なくともv1.xシリーズでは、誰もusing LinAlgと入力する必要はありません（名前がLinearAlgbebraになるとは思いませんが、架空の競合他社として作成しました） 。

明確にするために、標準のJuliaがロードされるため、何もインストールする必要はありませんが、エクスポートする名前を取得するには、 using LinAlgと記述する必要があります。

using LinAlgなしで*メソッドなどを取得するので、これは奇妙なところです。 （言い換えれば、 LinAlgはタイプの海賊です）。

はい、基本的にはここで線を引く必要があります。ベースは、LinAlgを海賊ではないようにするために必要なだけの線形代数機能を定義する必要があるため、 Arrayと*であるため、ベースでmatmulが定義されます。

具体的な例を挙げて、現在のインターフェースでどのように解決するかをお聞きします。これで、状況が明確になるかもしれません。

目標は、組成データを使用して因子分析を実行することです。 私はCompositionと呼ばれるタイプと、作曲の空間の内積を持っています。 私は多くのサンプル（たとえば岩石サンプル）を収集し、それらすべてを大きなVector{Composition}に入れます（たとえば、組成=％water、％grain、％air）。 ここで、このデータのベクトルに対して、別のパッケージ（MultivariateStats.jlなど）に実装されている因子分析アルゴリズムを呼び出します。 デフォルトinner製品をインポートせずに、これを一般的にどのように実装しますか？

最後のコメントから私が理解したのは、MultivariateStats.jlとCoDa.jlの両方がLinAlg.jlに依存する必要があるということです。 MultivariateStats.jlの依存関係は、名前innerをスコープに取り込むことだけです。 CoDa.jlの依存関係は、MultivariateStats.jlによって呼び出すことができるinnerのメソッドを定義することです。 それはあなたが提案していることですか？

Composition{D}は+と*の下の$ D次元ベクトル空間のようです。

双対ベクトル空間を定義したくなるでしょう。

したがって、 adjoint(::Composition) -> DualCompositionと*(::DualComposition, ::Composition) -> scalar （現在inner ）を定義できます。 DualCompositionは、 Compositionを内部に保持する以外はそれほど多くのことをする必要はありません。

https://en.wikipedia.org/wiki/Dot_productの最初の文は、 dotが任意の2つの反復可能オブジェクトに対する操作である可能性があることを示唆しているようです。 再帰的にしてNumberに対して定義し、 innerを抽象線形代数関数として定義することができます。これはたまたまNumberとAbstractArrayに対してオーバーラップします。

@andyferrisに感謝します、双対空間についてのあなたの考えに感謝します。 ただし、このタスクでは新しいタイプに依存したくありません。 最終的な解決策は不必要に複雑です。

私が理解したいのは、次のような理由です。

inner(x,y) = sum(x.*y)
norm(x) = sqrt(inner(x,x))

export inner, norm

ベースでは歓迎されませんか？ 言語のユーザーが専門とする関数名を一般的に定義するために必要なのはこれだけだと思います。 私はコア開発者の視点を理解するという真の関心を持ってこれらの質問をしていることを覚えておいてください。 会話が再び間違った方向に進む前に、私はこれを言いたいです。

数学全般に関心のある人の観点からすると、これらの概念をデフォルトでエクスポートせず、代わりにLinAlg内で定義するのは不自然に感じます。 LinAlgは、配列型のこれらの高レベルの概念の実装だと思います。 おそらく、私の作業全体で配列の線形代数は必要ありませんが、パッケージ全体の内積の概念（MultivariateStats.jl、Clustering.jlなど）の恩恵を受けることができます。 また、 LinAlgを依存関係としてパッケージに含めたくない場合があります。これは、そうではないためです。

さらに強調すると、配列に依存しない内積の概念があります。 この概念は、Baseのステートメントexport innerで表されます。 座標inner(x,y) = sum(x.*y)を表す配列のようなオブジェクトの内積の実装があります。 この操作は、必要に応じて、上記のようにBaseでのフォールバックメソッドとして定義できます。

ユースケースのもう1つの例は、クリロフ法です。 たとえば、内積を持つ関数空間がある場合は、クリロフ法を使用して、その無限次元関数空間の小さな有限次元部分空間で線形問題または固有問題を近似できます。

私もベクトル/ヒルベルト空間を形成するが<: AbstractArrayの一部ではない独自のオブジェクトを持っています。 ランクN>1の配列もベクトル空間を形成し、クリロフ法で「ベクトル」として使用できるというアナロジーから、 vecdotとvecnormの使用に依存するようになりました。内積とノルムの一般化された概念です。 そのため、関数を線形演算子として使用するKrylovメソッドを使用してパッケージを開発してきました。そのタイプのオブジェクトがvecdot 、 vecnorm 、およびいくつかをサポートしていれば、'ベクトルは任意のタイプにすることができます。その他のもの（ scale! 、 zero 、...）。 しかし、おそらくそれはBaseでこれらの概念が意味することを悪用しているので、ここで正しいインターフェースをまっすぐにするのは良いことです。

右- vecdotはinnerに名前を変更できます。

（今、 normが実際にmatrixnormと呼ばれるべきかどうか疑問に思っています。 normが常にinnerと一致する行列の場合。おそらく2つの異なるものがあるようです。 normで起こっていることは、それを一般化するのにいくつかの困難を引き起こしています）

実際、一般的なベクトルのようなオブジェクトの場合、ベクトル空間の次元を照会することも役立ちます（たとえば、私の例のユースケースでは、Krylovの次元が完全な空間の次元より大きくならないことを確認します）。 ネストされた配列の例は、 lengthがここでは正しい概念ではないことを示しています。つまり、これらの場合には、長さの再帰的な概念が必要になります。

ここで、ネストされた配列を一般的なベクトルとして使用する例では、 vecdotとvecnormは、＃25093で説明されているように、内積とノルムの正しい概念でさえない場合があります。 vecdotとvecnormを再帰的に呼び出さないでください。 これらの関数を一般的な内積およびノルム関数として解釈すると、＃25093がトリガーされますが、これはこれらの関数が意図された方法ではない可能性があります（代わりに意図されたものがわかりません）。

したがって、パッケージ全体で使用するためにここで一貫したインターフェイスが必要であることに同意します。したがって、中央の場所に属します（おそらくベースではなく、確かに標準ライブラリにあります。たとえば、 using VectorSpacesを実行する必要があります）。 ）。 ネーミングに関しては、2つのオプションがあります。

オプション1（これまでの私の解釈）：
接頭辞vecは、オブジェクトを一般的なベクトルとして解釈するときのそのオブジェクトのプロパティを示します。

• ネストされた配列のvecdotとvecnormが修正されました（PR＃25093）
• 新しいveclength定義が追加されました

オプション2（おそらくより良い）：より数学的に正しい名前を使用する

• inner
• dimension
• しかし、 normをどうするか？

そして最後に、 @ stevengjにpingを送信するだけで、彼には確かにいくつかの有用なコメントがあります。 ご不便をおかけして申し訳ございません。

名前は、これらすべての中で最も興味深い部分ではありません。 関数dotを使用して、任意のヒルベルト空間の一般的な内積を参照することに問題はありません。 たとえば「2つの関数の内積」には他に合理的な意味がないだけでなく、特に有限次元ベクトルへの類似性を強調しようとしている教育学的設定では、非公式な使用法で「関数の内積」を見るのはかなり一般的です。スペース。

@juliohm 、 inner(x,y) = sum(x.*y)は一般に内積でさえないので、これはベースに入れるにはかなりひどいフォールバックになります。

しかし、 dotは、ベクトルとして動作するBase内のさまざまなオブジェクト（ランクN>1の配列やネストされた配列（ネストされたベクトルが唯一のケース）など）の正しい内積をすでに計算していません（実際には失敗します）。正しく機能する場所）。 さらに、一般名normは行列に対してあいまいになります。これは、これが誘導ノルムを返すという現在の選択に同意するためですが、「ベクトルノルム」（フロベニウスノルム）も必要になる場合があります。

したがって、私の最も影響の少ない提案は、セマンティクスvecnorm(x) = norm(vec(x))を手放し、 vecnorm(x)を「 xが、ベクトル空間、 x "の対応するベクトルノルムを計算します（ vecdotと同様）。 これは解釈（したがってドキュメント）の変化ですが、Baseのオブジェクトの実際の実装/アクションはそれほど変わらず（PR＃25093）、ほとんどの場合（ランクN配列）で同じ結果を生成します。スカラーまたはベクトルの）。 xの対応するベクトル空間次元を返す関数veclength(x)は、インターフェースを完成させます。

カスタムパッケージは、ベクトルとして動作する新しい型を定義するときに、これらの関数の実装を学習する必要があります。

非公式な使用法で「関数の内積」を見るのはかなり一般的です。特に、有限次元のベクトル空間への類似性を強調しようとしている教育学的設定ではそうです。

名前は重要なので、重要ではないとは言わないでください。 n回繰り返します。内積と内積は同じものではありません。 抽象ヒルベルト空間での作業を公開する深刻な資料では、「ドット」を使用することはありません。 私の言葉よりもウィキペディアを信頼したい場合は、コピーして貼り付けた定義を次に示します。

内部製品

線形代数では、内積空間は内積と呼ばれる追加の構造を持つベクトル空間です。 この追加の構造は、空間内のベクトルの各ペアを、ベクトルの内積として知られるスカラー量に関連付けます。

ドット積

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

言語の用語と数学的一貫性を改善するためのこの抵抗は、意欲をそそります。 私があなたに提示する事実の数に関係なく、例やユースケースの数に関係なく、「私はドットで大丈夫です」以外の反論はありません。

@juliohm 、用語は慣例の問題であり、正確さではありません。 ヒルベルト空間、特に無限次元空間の正式な使用法では、「内積」という用語がほとんど排他的に使用されることに同意します。 しかし、私が言ったように、「ドット積関数」をグーグルで検索すると、その用語の非公式な使用法もたくさん見つかります。 「このヒルベルト空間の2つの要素の内積を取る」と言うと、すべての数学者は、無限次元の空間であっても、内積を参照していることを知っているので、他にないので、混乱の本当の危険はありません。 「ドット積」という用語の標準的な一般化。 そのため、「ドット」と「内部」のスペルの議論が中心的な問題であるとは思いません。

ここで必要なセマンティクスと、新しいヒルベルト空間またはバナッハ空間を定義する場合に型が実装する必要のある関数のセットを決定することが重要です。 現在、新しいヒルベルト空間を表す型を定義する場合は、おそらくdotとnormを定義する必要があります（現在、後者のフォールバックがないため）。 adjointだと思います。双対空間オブジェクトへのマッピングが必要な場合は

@Juthoが言うように、これは配列の配列の場合によってすべて複雑になります。これは、そこに必要な可能性のあるものが複数あるためです。 考えられるすべてのセマンティクスに標準化された名前があるわけではないため、すべての人を満足させる名前/セマンティクスを見つけるのは困難です。 vecdotセマンティクスの説明については、＃25093を参照してください。 私自身、ここでは良い答えがありません。

ここでいくつかの可能性

1. x[i]' * y[i]の合計。 現在、これはdot(x,y)です。 行列のベクトル（行列を与える場合）の内積ではなく、現在、多次元配列のすべてが定義されているわけではありません。
2. 多次元配列を含むdot(x[i], y[i])と、 Number $の場合はconj(x)*yの合計。 現在、これはvecdot(x,y)です。
3. 一部の関数、たとえばinner(x,y)は常に真の内積であると定義されており、配列の場合は合計inner(x[i],y[i])になります。これは、本質的に@Juthoが必要とする「再帰的内積」です。 しかし、行列Aの場合、この内積は、現在のnorm定義である誘導ノルムnorm(A)と矛盾します。 これを修正するには、行列のnorm(A)をデフォルトでフロベニウスノルムに変更する必要があります。これは、広範囲にわたる重大な変更になる可能性があります。

質問（＃25093で部分的に説明されています）は、Baseでこれらの3つすべてが必要かどうか、または2つ（およびどの2つ、そしてそれらを何と呼ぶか​​）で逃げることができるかどうかです。 @Juthoの提案は、私が理解しているように、基本的にBaseのオプション2を削除し、オプション3にvecdotとvecnormを使用することです。はジュリアにかなり独特で、たとえば無限次元のヒルベルト空間では少し奇妙です。 もちろん、それは世界の終わりではありません。

もう1つの可能性（ vecdotで行うこととは多少関係ありません）は、 dotが真の内積である必要があることを（戻る）ことです。 つまり、動作1を削除し、 dot(x::AbstractVector, y::AbstractVector)をsum dot(x[i],y[i]) $と等しくします。 それでも、多次元配列に対しては定義しないでください（ normとの一貫性を保つため）。

私の現在の個人的な傾向は、 dotを真の内積（ normと一致している必要があります）として定義し、ベクトルのdot(x[i],y[i])の合計に変更することです（つまり、行列のベクトルの場合）、多次元配列に対しては定義しません。 次に、 vecdotを定義して、 @ Juthoが提案するように、フォールバックvecdot(x,y) = dot(x,y)を使用してvecdot $を再帰的に呼び出します。 最後に、新しい「ヒルベルト空間」タイプはdotとnormを定義する必要があると言います。 これは、私にとって最も混乱が少なく、最も理解しやすい変更のように思えます。

（ norm(x) = sqrt(real(dot(x,x)))フォールバックも可能ですが、スプリアスオーバーフローに対して脆弱であるため、多少危険です。技術的な理由から、フォールバックとしてsqrt(dot(x,x))を使用できないことに注意してください。 Realの結果であり、 Complexの結果ではありません。）

この有益な反応をありがとう@stevengj 。 ちょっとしたコメント：

フォールバックvecdot(x,y) = dot(x,y)使用します。 最後に、新しい「ヒルベルト空間」タイプはdotとnormを定義する必要があると言います。

それには2つの問題があります。 $＃ vecdotは、一般的なイテレータを処理するためのAny引数をすでに受け入れているため、 vecdot(x,y) = dot(x,y)フォールバックは存在できません。 2番目の問題は、 dotとnormが、ユーザータイプのようなベクトルが定義する必要のある真の内積とノルムにさらされている場合、たとえばKrylovメソッドを使用してパッケージを作成する場合でも完全に一般的なベクトルのような型で機能するはずですが、ユーザーがネストされた配列または多次元配列をベクトルのようなオブジェクトとして使用したい場合は、まだ機能しません。 したがって、 vecdotとvecnormは、一般的な内積であり、ベクトルのようなオブジェクトのノルムであると私は主張します。 これは、行列の場合、ほとんどの人が実際にnormが誘導された行列/演算子のノルムであることを期待しているという事実ともよく一致します。

実際のユースケースについて（これが例外的なケースではないことを示すため）。 確率行列は最大の（ペロン-フロベニウス）固有値を持ち、対応する固有ベクトルは固定小数点確率分布を表します。 その量子一般化では、確率分布は正定値行列（密度行列）に一般化され、そのような行列は完全に正のマップ、つまりマップrho -> sum(A[i] rho A[i]^\dagger for i = 1:N)の固定点（最大固有値に対応する固有ベクトル）です。したがって、 rhoは密度行列であり、 A[i]はすべてのiの行列です（完全に正のマップを表すKraus演算子として知られています）。 行列の次元が大きい場合、固定小数点密度行列を見つけるにはアーノルディ法が最適です。

私の現在の個人的な傾向は、ドットを真の内積（ノルムと一致している必要があります）として定義し、ベクトルのドット（x [i]、y [i]）の合計に変更することです。 最後に、新しい「ヒルベルト空間」タイプはドットとノルムを定義する必要があると言います。

それはすでに大きな改善です。 Baseでinnerセマンティクスを持つようにdotを文書化すると、少なくともユーザーは不要なライブラリをインポートせずに独自のスペースを定義できます。 名前付けには満足していませんが、少なくとも機能は必要な人が利用できるようになります。

はい、「ヒルベルト空間」タイプに実装するための文書化されたインターフェースがあると便利だと思います。

もちろん、ベクトル空間のこの一般的なインターフェイスについて考えると、上記のようにnormが含まれている場合、それは行列のフロベニウスノルムになるはずです（すべての配列はベクトルの要素であるため、高次元配列の場合は一般化してください）スペース）。 その場合、行列用に別の「演算子ノルム」関数（ matnormまたはopnormなど、またはnormのキーワード引数...）が必要になります。

@andyferris 、私の最後のコメントに注意してください。 normとdotは、高次元配列やネストされた配列など、Juliaのオブジェクトのようなベクトルでも機能しないため、一般的なヒルベルト空間インターフェースにはなりません。 したがって、 vecdotとvecnormは、このための「より良い」（最も壊れにくいという意味で）候補です。

このトピックを復活させることは、近い将来、この言語で行うと予想される数学のタイプに非常に関連していると思います。 内積の一般性とセマンティクスを改善するために何が行われるかについてのコンセンサスはありますか？

これが、積に関する私の個人的な数学オントロジーの一部です。
それが記憶を磨く/コンセンサスをもたらすのを助けることができれば

• ドット積; 同義語：スカラー積
• 内部製品
• クロス積
• テンソル積; 同義語：外積
• ウェッジ製品; 同義語：外装製品
• カップ積
• 三重積

ボーナス：ウィキペディアの審判はありません

この時点で、＃25093での@Juthoの提案は、このコンテキストではvec*の用語が少し奇妙ですが、最も混乱の少ない変更のように見えます。

vec*の用語がおかしいことに同意します。 そのため、関数の名前を標準名に変更すると、すべてのユーザーにとって有益になります。

同様に、 vec*の用語が奇妙であることに同意します。

vecdotの代わりに、新しいメソッドinnerを導入することもできますが、 vecnormを「置き換える」ための適切な名前がわかりません。 実際、 vecnormが悪いとは思いません。ベクトルノルムは、必要な操作の十分に確立された明示的な用語です。

ここでの基本的な問題は、通常のnorm(A)が内積に対応しない行列と多次元配列、および上記の配列の配列にあります。 これらの場合、どの内積が意図されているかを示すために、ある程度の曖昧性解消（たとえばvec*またはfro* ）が必要です。

デフォルトでvecdotに設定されているinner関数を使用することもできますが、同じ関数に2つの名前を付けるのは少しばかげており、ノルムを何と呼ぶか​​という問題があります。

また、 vecdotの名前は奇妙だと思います。実際、それが存在することすら知らず、そのために独自の関数を作成していました... innerと呼ばれます。

私の理解では、奇妙なvecdotを廃止して、 inner $を優先し、ユーザーが独自のスペースを実装するための内積セマンティクスを与えることができます。

normについては、わかりません。 私はこの問題を開いて内積について議論しました。おそらく、Baseの規範の状態について議論するために別の問題が適切であるでしょう。

vecdotとvecnormの代わりに、$ inner(x,y)とinnernorm(x) = sqrt(inner(x,x)) （オーバーフローを回避するために最適化された特殊なケースを使用）を使用できると思います。 innernormは少し珍しいですが、文脈上はかなり明確です。

この変更に賛成です。 innerとinnernormという名前は明確で、概念と一致しています。 彼らがJuliav1.0に到達できたらいいのにと思います。

innerとinnernormは私には問題ないようです。

私の意見では、私たちのnorm関数は、Juliaの汎用関数とディスパッチシステム、およびディスパッチが行われるべきではない「クリアインターフェイス」と呼ばれるものにあまりうまく適合していません。セマンティックの選択、実装の選択だけ。 個人的には、「 normはベクトル空間の要素のノルムを返す」と言うことができます。ここで、行列と線形演算子は依然としてベクトル空間の要素です（これらを追加してスカラーを掛けることができます） 。 たとえば、「 opnormは線形演算子の演算子ノルムを返す」（またはmatnormなど）を使用することもできます。

現時点では、「 normは、要素が線形演算子でもない限り、ベクトル空間の要素のノルムを返します。線形演算子の場合は、代わりに演算子ノルムを提供します」。 個人的には、派遣は決して驚くべきことではないと感じています。

つまり、常にベクトルノルムを実行する関数と、常に演算子ノルムを実行する別の関数を好みます。両方を実行しようとする関数はありません。

@andyferris ：+1：空間内の内積によって誘発される規範ではない特定の規範は、より具体的な名前を持つことができます。 normという名前は、正確にnorm(x) = sqrt(inner(x,x))を意味し、ユーザータイプの必要に応じて再定義できます。

個人的には、「 normはベクトル空間の要素のノルムを返す」と言えます。

現在のnorm関数は、その定義を満たしています。 行列の場合、ベクトル空間の完全に有効なノルムである誘導（演算子）ノルムを計算します。 （ベクトル空間は内積や規範を持っている必要はありません。）

演算子ノルムが「ベクトル空間のノルム」ではないと考える場合、「ノルム」の定義について多少混乱するかもしれません。

これは、 normとinnernormの便利な違いでもあります。 normを定義する場合、それはあなたがバナッハ空間（または少なくともノルムベクトル空間）を持っていることだけを意味すると言います。 innernormを定義すると、ヒルベルト空間（または少なくとも内積空間）があり、このノルムがinnerと一致していることを意味します。

たとえば、適応数値積分（ala quadgk）は、内積空間ではなく、ノルムベクトル空間のみを必要とするものです。

確かに、申し訳ありませんが、私はおそらく私の言語に少し不正確でした。 さまざまな演算子ノルムを含む、ベクトル空間には明らかに多くの有効なノルムがあります。

私が得ているのは、暗黙的ではなく明示的であるという基準の選択を好むかもしれないということだと思いますか？ また、同じ関数を使用すると（たとえば、追加のキーワード引数なしで）、「同じ」ノルムが得られます。この場合、ユークリッドはAbstractArrayに対していくぶん防御可能な選択のように見えます。

これは、 normとinnernormの便利な違いでもあります。 ノルムを定義する場合、それはあなたがバナッハ空間（または少なくともノルムベクトル空間）を持っていることだけを意味すると言います。 innernormを定義する場合、ヒルベルト空間（または少なくとも内積空間）があり、このノルムがinnerと一致していることを意味します。

これは理にかなっているように見えますが、オブジェクトにinnernormがある場合、別のnormが必要になるのはなぜでしょうか。 あるいは、バナッハ空間のインターフェースにはnormが必要ですが、内積空間のインターフェースはnormとinnerの両方を提供することを提案します。 これらの関数は、必要に応じてバナッハまたは内積空間のオブジェクトを期待する汎用コードで使用できます（編集：バナッハ空間で機能するコードは自動的に内積空間でも機能すると考えられます）。

norm(x)は常に、ある種の要素ごとのユークリッドノルム（つまり、行列のフロベニウスノルム）を参照していると提案していると思います。つまり、基本的にvecnormは再帰の場合を法としてしています。 この場合、 dot(x,y)を対応する内積に再定義することもできます（ innerも機能しますが、 dotには中置バリアントx ⋅ yの利点があります）。

原則としてこれで問題ありませんが、これは重大な変更であり、0.7の前に少し遅れる可能性があります…

L2は高次元でも良いデフォルトですか？
この記事は距離について話しますが、それは規範にも関係する可能性があります
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

この場合、dot（x、y）を対応する内積になるように再定義することもできます（内積も機能しますが、ドットには中置バリアントx⋅yの利点があります）

dot完全に取り除くことはできますか？ 中置記法は、 dotという関数の存在とは無関係である必要があります。 Julia配列のinnerメソッドを使用して中置を定義するだけです。 それは可能ですか？

それが実際の内積です。ユークリッド幾何学のR^nのxベクトルとyベクトルの間の内積の便利な表記x⋅yです。

@stevengjそれは良い要約だと思います。

@ o314 L2は高次元の良いデフォルトですか？ おそらくそうではありませんが、たとえばnorm(v::AbstractVector)によって選択されたノルムが$＃$ length(v) ＃$に依存している場合は、本当に嫌いです:)行列か高次元配列かを二度と推測したくないのですが、 「L2には大きすぎます」-おそらくこれはユーザーが明示的にマークする必要があると思いますか？

@juliohmそれは間違いなく可能ですが、前述のように、これらは私たちが提案している破壊的な変更です。 （繰り返しますが、再帰的な場合に何をすべきか、およびinnerとdotの間の考えられる違いに関する以前の議論を法として）。

@stevengj 、 @ andyferrisが意味することの私の解釈は、ダックタイピングのために、ユーザーがオブジェクトをベクトルとして解釈したいかどうかを判断するのが難しいということです（そして対応するベクトルp -normを使用します）または演算子として（そして誘導されたp -normを計算します）。 したがって、どのような動作が必要かを明示的に指定する以外に選択肢はないと思います。 現在のアプローチは、 normが入力に基づいてベクトルノルムと誘導ノルムのどちらを選択するかを暗黙的に推測しようとするという意味で少し奇妙です。 vecnormは、必要なことを明示的に指定する方法です。ベクトルノルム（これがvecnormのような悪い名前を見つけられない理由でもあります）。 より根本的な変更は、 normを常にデフォルトでベクトルノルムにし、（キーワード）引数または別の関数を使用して、誘導ノルムが必要な場合に明示的に指定することです。

一方、私はinnernormという名前も気にしません。これは、これが内積ベースの標準であるという点で明示的です（つまり、ユークリッドの場合は常にp=2 ）。 カスタムオブジェクトの(vec)normがインターフェイスの一部としてオプションの引数pをサポートする必要があるかどうかを判断するのは難しいと思います。私のユースケースの中には、 p=2だけが簡単だからです。計算します。

それが実際の内積です。ユークリッド幾何学のR^nのxベクトルとyベクトルの間の内積の便利な表記x⋅yです。

一般的な（複雑な）ベクトル空間のコンテキストでx ⋅ yという表記を見たことを思い出せないという意味で、私はこれに同意します。 このような場合、数学表記(x,y)またはディラック表記< x | y >のみが使用されると思います。 電磁気学では、3次元ユークリッド空間のベクトルにE ⋅ Bを使用することが多く、複素数表記（つまり、フェーザ）を使用しても、これは複素共役を意味しません。 必要に応じて、そのような場合、複素共役が明示的に示されます。 したがって、 dotが複雑なまたはエルミート共役なしsum(x_i * y_i)になり、 innerが一般的な内積空間の正しい内積になったとしてもかまいません。 残念ながら、これはおそらく単一のリリースサイクルでは実行できません。

L2は高次元の良いデフォルトですか？ おそらくそうではありませんが、たとえば、norm（v :: AbstractVector）によって選択されたノルムがlength（v）に依存している場合は、本当に嫌いです:)行列または高次元配列が「L2には大きすぎます」-おそらくこれはユーザーが明示的にマークする必要があると思いますか？

私は2Dと3Dを扱うBIMの世界で働いていますが、4d、5d、6dは7dかもしれません。 これ以上進むことはありません。 どの時点でも、どの次元で作業し、どのアルゴが関与しているかがわかります。 それで十分です。

MLや情報検索などで働く人の視点を表現することはできません。そこには、norminfの方がいいかもしれません。 私のハメ撮りで重要なのは推測可能性と安定性です。 MLの人々が自分たちのものに異なるデフォルトを必要としても、私はまったくショックを受けません。 混乱がなければ。 例えば。 コンパイル時に明示的かつ静的に決定されます。 それがアルゴスの適用中に安定して一貫している場合、それはさらに贅沢です。

array：similarからインスピレーションを得ています。完全には実装されておらず、テストされていません。

norm2 = x -> x |> inner |> sqrt
norminf = ...
NMAX = 10
for N in 1:NMAX
    <strong i="13">@eval</strong> begin norm(a::Array{T,N}) where {T} = norm2 end
end
norm(a::Array{T,n}) where {T} = norminf

ドットを完全に取り除くことはできますか？ 中置記法は、ドットと呼ばれる関数の存在とは無関係である必要があります。 Julia配列のinnerメソッドで中置を定義するだけです。 それは可能ですか？

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L498
vecdot(x::Number, y::Number) = conj(x) * y # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L657
dot(x::Number, y::Number) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L659
function dot(x::AbstractVector, y::AbstractVector) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L677

# Call optimized BLAS methods for vectors of numbers
dot(x::AbstractVector{<:Number}, y::AbstractVector{<:Number}) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L698

Dot / vecdotは、共役を使用し、いつBLASに移動するかを決定することを意味します。 これはどこかで処理する必要があります。 ただし、これは単一の名前空間で管理できる必要があります。

L2は高次元の良いデフォルトですか？ おそらくそうではない

L2は、無限次元空間（関数など）の最も一般的な基準でもあります。 任意のベクトル空間を期待するのが妥当なデフォルトだと思います。

もちろん、他の規範も利用できるようにしたいのです。 norm(x)を可能な限り要素ごとのL2に再定義すると、 norm(x, p)は要素ごとのLₚになり、対応する誘導/に対して他の関数（ opnormなど）が必要になります。作用素ノルム。

一般的な（複雑な）ベクトル空間のコンテキストでx ⋅ yという表記を見たことを思い出せないという意味で、私はこれに同意します。

別のスレッドIIRCでいくつか引用しました（たとえば、BLASは複雑な内積にdotを使用し、関数の内積の用語を使用しても教育学的ソースを見つけることができます）。 まさに「内積」という用語は、通常、「内積の一般化」と呼ばれます。 ユークリッド内積のdotの表記に驚く人はいないと思います。また、中置演算子があると便利です。

もちろん、 dotをそのままにして、 innerを導入することもできますが、それは紛らわしい二分法を生み出すと思います。最も一般的なケースでは、関数は同等ですが、奇妙なケースでは（例えば、行列の配列）それらは異なります。

しかし、繰り返しになりますが、変更を壊すには少し遅れる可能性があるため、 innernormとinnerに頼らなければならない可能性があります。 いずれにせよ、誰かができるだけ早くPRを作成する必要があります。

コンセンサスフォームの合理的な尺度があれば、関連する（短い）タイムスケールでの実装の調査にある程度の帯域幅を費やすことができるかもしれません。潜在的な重大な変更が含まれます。 これらの操作のセマンティクスを明確にし、明示的な名前を付けるという意欲に感謝します。 一番！

2つの主なオプションがあります。

• ノーブレーク、機能を追加します： inner(x,y)およびinnernorm(x) 。 vecdotとvecnormを置き換え、配列の配列を再帰的に処理します。

• 速報： norm(x,p=2)を常に要素ごとに再帰的に変更し、 vecnormを置き換え、演算子/誘導ノルムに新しい関数opnormを導入します。 vecdotを置き換えて、対応する要素ごとの内積をdot(x,y) $にします。 （または、名前をinnerに変更しますが、中置演算子があると便利です。 dotとinnerの両方があるのは面倒です。）

ゼロから設計する場合は2を選択しますが、 normの意味を黙って変更するには混乱が大きすぎる可能性があります。

中間オプションの1つは、 innerとinnernormを定義し（ vecdotとvecnormを廃止）、 norm(matrix)をopnormに廃止することです。 norm(matrix) = innernorm(matrix)を再導入します。 そうすれば、最終的にはinnerとnormを使用できるようになり、 dotを配列のベクトルの現在の奇妙な獣として残します（ innerと一致します）。数値のベクトルの場合は

innernormの奇妙な点の1つは、L1またはLinfの「要素ごとの」ノルムを指定する方法が必要なことですが、どちらも内積に対応していないため、 innernorm(x,p)は少し誤称です。

私はあなたの中間オプションが好きです。

上で述べたように、私はinnernorm(x)という名前が好きです。これは、 p=2を意味し、2番目の引数があってはならないからです。 内積ノルムの計算方法しか知らないオブジェクトがあります。 しかし、現在の(vec)normでは、 p引数が想定されるBaseインターフェイスの一部であるかどうかが不明であるため、2番目の引数を省略するか、サポートするかがわかりません。ただし、 p != 2を明示的にチェックすると、エラーが発生します。

しかし、提案の中間段階で非推奨ではない方法でvecnorm(matrix, p!=2)を実行できないという問題があります。

また、中間オプションも気に入っています。すぐに重大な変更を加えるのではなく、規範の非推奨の適切なサイクルを確実に実行したいと考えています。 （ユーザーとして、重大な変更は私を怖がらせますが、v1.0のコードの非推奨を修正することは、将来のためのクリーンで明確なコードへの投資のようなものだと思います）。

実際にinnernormが必要ですか、それとも今のところvecnormを使用できますか（後でnormを優先してvecnormを廃止します）？

dotをinnerに置き換えるだけでは、実際に騒ぎが起こる可能性はありません...内積がドット積の一般化であることも十分に明らかだと思います。

変更は、2つの別々のPRで実装できます。

1. dotをinnerに置き換えて、一般的な意味を付けます。 必要に応じて、中置\cdot表記がJulia配列間の内側を指すようにします。
2. 規範の変形と用語に関するさらなる議論と非推奨のサイクル。

私の理解では、PR1はJuliav1.0より前にマージされる可能性があります。 壊れていません。

dotをinnerに置き換えても、 dotは現在、配列の配列の真の内積ではないため、壊れることになります。したがって、名前を変更するだけでなく、意味を変更することになります。 私は意味を真の内積に変更するためのものですが、意味を変更しても（真の内積として定義する）、 dotと綴り続けることに問題はありません。

したがって、0.7では次のことができます。

1. norm(matrix)をopnorm(matrix)に、 norm(vector of vectors)をvecnormに廃止します。
2. $ sum dot([vector of arrays], [vector of arrays])を非推奨にします。
3. vecdot(x,y)とvecnorm(x, p=2)がユークリッド内積/規範（ p=2の場合）であり、それらを再帰的にするとします（これは少し壊れていますが、実際にはおそらく大したことではありません） 。

次に、1.0では：

1. vecnormをnormに、 vecdotをdotに廃止します。 （これが1.0リリースルールで許可されているかどうかわからない、@ StefanKarpinski？）

（驚くべきことに、 numpy.inner関数は必ずしも内積ではないことに注意してください。しかし、 innerとdotに関するNumPyの用語は、しばらくの間奇妙でした。）

私がそれをdotとつづ​​り続けることを好む理由：

• 中置スペルがあると便利です。
• 通常の有限次元ベクトル空間を操作する非数学者にとって、 dotはユークリッド内積のより一般的な名前です。 （数学者は、任意のヒルベルト空間の内積関数にdotという名前を使用することに簡単に慣れます。「内積」は、そのような空間に他の可能な意味はありません。）
• innerとdotの両方があると、混乱する場合があります。一致する場合もあれば、一致しない場合もあるためです（現在のdotの意味を維持する場合）。
• 線形代数以外では、 innerはコンピュータサイエンスで他の多くの潜在的な意味を持っているため、Baseからこの名前をエクスポートするのはやや面倒です。

インナーという名前に対する反対について詳しく教えてください。 まだ分​​からない
このスレッドのすべての人が用語に反対することを好む理由は
同意する？

2018年5月15日火曜日、午前5時13分スティーブンG.ジョンソン[email protected]
書きました：

（numpy.innerに注意してください
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
驚くべきことに、関数は必ずしも内積ではありません。）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
。

理由のどれも私に説得力がありません：

>>

• 中置バリアントがあると便利です。

はい。名前を変更しても、中置記法は引き続き存在できます。
上で説明したように内側。

>>

• 通常の有限次元で動作する非数学者向け
  ベクトル空間、ドットはユークリッド内部のより一般的な名前です
  製品。 （数学者は、名前のドットを使用することに簡単に適応します
  任意のヒルベルト空間の内積関数—「内積」には
  そのようなスペースの他の可能な意味。）

この議論は良くありません：普通の人々に間違ったことを教えましょう
彼らは怠惰であり、新しい適切な単語を学ぶことができないため、用語、
そして数学者に彼らの意志に反して間違った用語を使うように強制します。

>>

• 内側とドットの両方があると混乱します。
  一致する場合もあれば、一致しない場合もあります（現在のドットを保持する場合）
  意味）。

両方は必要ありません。あまり一般的ではない名前を削除してください。
この時点でドット。

>>

• 線形代数の外では、内部には他の多くの可能性があります
  コンピュータサイエンスにおける意味、したがってそれはやや厄介です
  この名前をBaseからエクスポートします。

線形代数の外で、私はドットの多くの用途を見つけることができます。 さらに多くの
完全に異なることを意味するドット中置記法。

>>

@juliohmの最後の投稿を固定フォーマットで再投稿しています。

理由のどれも私に説得力がありません：

中置バリアントがあると便利です。

はい。上で説明したように、innerへの名前変更に関係なく、中置記法は引き続き存在できます。

通常の有限次元ベクトル空間を操作する非数学者にとって、ドットはユークリッド内積のより一般的な名前です。 （数学者は、任意のヒルベルト空間の内積関数に名前ドットを使用することに簡単に適応します。「ドット積」は、そのような空間に他の可能な意味はありません。）

この議論は良くありません。怠惰で新しい適切な単語を学ぶことができないので、普通の人々に間違った用語を教えましょう。そして数学者に彼らの意志に反して間違った用語を使わせます。

内側とドットの両方があると混乱する場合があります。これは、一致する場合もあれば、一致しない場合もあるためです（現在のドットの意味を維持する場合）。

両方は必要ありません。あまり一般的ではない名前を削除してください。この時点でドットであることに同意します。

線形代数以外では、innerはコンピュータサイエンスで他の多くの潜在的な意味を持っているため、Baseからこの名前をエクスポートするのはやや面倒です。

線形代数の外で、私はドットの多くの用途を見つけることができます。 完全に異なることを意味するドット中置記法についてはさらに。

はい。上で説明したように、innerへの名前変更に関係なく、中置記法は引き続き存在できます。

const ⋅ = innerを定義することはできますが、用語に一貫性がありません。 「ドット積」を一般的な内積として使うのは嫌いだと思いましたか？

数学者に彼らの意志に反して間違った用語を使用するように強制する

数学者は、用語が正しいことでも間違っていることでもないことを知っています。それは従来型または非従来型（そしておそらく一貫性または一貫性がない）にすぎません。 （そして、ほとんどの人は、規範的なスペリングに情熱を持っているので、数学には入りません。）私の経験では、量子力学ではベクトルは「状態」と呼ばれ、随伴作用素は「短剣」と呼ばれます。二重ベクトルは「ブラ」と呼ばれ、それらは崇高に無関心です。 同様に、ジュリアでは内積がdot(x,y)またはx ⋅ yと綴られていると言っても、経験豊富な数学者が2回以上点滅することはないと思います。特に、用語はすでに理解されているためです。多くの文脈での同義語。 （「この関数空間で2つの関数の内積を取る」と言うと、内積を参照していることをすぐに知らない数学者が見つかるとは思えません。）

一方、訓練を受けた数学者ではなく、抽象的な内積空間に触れたことがない人（つまり、大多数のユーザー）にとって、私の経験では、なじみのない用語はより障害になります。 「ジュリアで2つのベクトルの内積を取得するにはどうすればよいですか？」 FAQになります。

セマンティクスを選択する以外に、ここで解決すべき数学的な問題は実際にはありません。 スペルの質問は、純粋に利便性と使用法の1つです。

線形代数の外で、私はドットの多くの用途を見つけることができます。 完全に異なることを意味するドット中置記法についてはさらに。

ジュリアと他の多くのプログラミング言語が何年もの間dotを持っていて、それが問題ではなかったことを除いて。 innerは新しい破損になります。

最終的に、この（または他の）関数のスペルは、セマンティクスや非推奨パスと比較して小さな問題ですが、バランスのヒントはdotを支持すると思います。

確かにconst⋅=innerを定義できますが、用語に一貫性がありません。 「ドット積」を一般的な内積として使うのは嫌いだと思いましたか？

まだ分​​からないと思います。 ドットを内積と呼ぶことに矛盾はありません。 これは内積であり、私たちの多くにとって非常に具体的で役に立たないものです。 sum(x.*y)を超えるものはありません。

dotという用語がinnerのセマンティクスを持つJuliaで終わる場合、これは歴史的な災害であり、多くの人がイライラすることを保証できます。 教室で教授が次のようなことを説明するのを予見できます。「ご存知のとおり、これから空間の内積を定義しますが、ジュリアでは誰か（@stevengj）がそれをドットと呼ぶことにしました。」

それが起こった場合に備えて、今後の参考のためにこのスレッドのスクリーンショットを撮ることを確認します。

@stevengjがdotの用語を主張しているのはあなただけであり、他の誰もそれに反対を表明していません。 決断を下す前に、この事実を再考できればいいのにと思います。

これは内積であり、私たちの多くにとって非常に具体的で役に立たないものです。 sum（x。* y）に過ぎません。

「内積」がℝⁿのユークリッド内積のみを参照できると考える場合は、 const ⋅ = innerを定義するのではなく、 ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y)のみを定義する必要があります。

両方の方法を使用することはできません。 innerは⋅を中置同義語として使用できます（この場合、中置演算子は用語で「間違って」おり、名前に一貫性がありません）。中置同義語はありません（1つの特別な場合を除く）。

教室で教授が次のようなことを説明するのを予見できます。「ご存知のとおり、これから空間の内積を定義しますが、ジュリアでは誰か（@stevengj）がそれをドットと呼ぶことにしました。」

ハハ、私はこの架空の憤慨した教授から熱を奪うつもりです。 真剣に、「ドット積」という用語がℝⁿでのみ使用されていると思う場合、またはこの用語が他のヒルベルト空間で使用されている場合、数学者が憤慨していると思う場合は、もっと調べる必要があります。

これは歴史的な災害になります

真剣に？

この議論は、歓迎的で市民的で建設的な環境と考えられるものを超えて侵食されているようです。 意見や背景は異なりますが、個人的な攻撃や誰かを非難することは控え、すべての当事者が誠意を持って自分の主張について議論していると想定してください。

教室で教授が次のようなことを説明するのを予見できます。「ご存知のとおり、これから空間の内積を定義しますが、ジュリアでは誰か（@stevengj）がそれをドットと呼ぶことにしました。」

ここで、スティーブンが教授であることに注意することも価値があるかもしれません。 ：ウィンク：

私はまた、 inner dotを削除することについても危機に瀕しています。 dotという用語は非常に広く使用されており、PythonやMATLABの場合、Juliaに関数がないのは驚くべきことです。 ただし、ℝⁿ以外のベクトル空間、特に行列に適していることを考えると、 innerという用語も気に入っています。

ちなみに、Juliaでどのメソッドが実行されているかをテストしているときに、 dotが実際のベクトル/行列でのみ機能することに気付きました。 それは意図的なものですか？

内側とドットの両方があると混乱する場合があります。これは、一致する場合もあれば、一致しない場合もあるためです（現在のドットの意味を維持する場合）。

@stevengj vecdotをinnerに置き換え、 dotを維持するのは完全にばかげていますか？ 現在、あなたが説明しているその正確な問題は、 inner vecdotだけで、すでに存在しています。

OK ...楽しみにしています、ライブの提案は何ですか？ 彼らは：

• 幅広いタイプの一般的な内積としてdotを採用します。 ベクトルのベクトルではすでに正しく再帰的ですが、行列などで機能するようにします（ @jebej dotとinnerの両方があると、それほど便利ではないと思います。スティーブンは、少なくとも口語的にdotを使用して内積を意味することがよくありますが、これは誤りではありません。これは単なる用語です）。
• normを上記のdotと、すべてのAbstractArray全体でもう少し一貫性のあるものにすることを検討してください。最終的には、演算子基準にopnormを導入します（ AbstractMatrix ）および適切な非推奨の後に（新旧表記で） norm(matrix) == vecnorm(matrix)を持ちます。 この時点で、おそらくvecdotとvecnormもう必要ありませんか？

そうですか？ これらは、少なくとも、ジェネリックコードが内積空間を操作するための信頼できるペアとしてdotとnormを使用できる、「クリーンな」インターフェイスを備えた比較的一貫した線形代数のストーリーに到達すると思います。タイプに依存しません。

@andyferris 、はい、この変更を行う場合、必要なのdotとnormだけだと思います（これらは現在、任意の次元の配列または配列の配列に対する再帰的なユークリッド演算ですがノルムの場合、 norm(x,p)をp-ノルムとして定義します）およびopnormであり、 vecdotまたはvecnormはなくなります。

dotは現在、行列のベクトル（＃22392）の真の内積ではないため、 dotへの変更は重大な変更であることに注意してください。これは、＃22220（＃22220（その時点で、 vecdotを削除することはIIRCとは見なされませんでした）。 ただし、これは0.7で導入されたため、実際にリリースされたコードを壊すことはありません。 実際、0.6のdotは、多少偶然ですが、すでに任意次元の配列上のユークリッド内積です（＃22374）。 ここで提案されている変更は、その0.6の動作を復元および拡張し、それと一致するようにnormを変更します。

1つの質問は、 norm(x,p)がnorm(x[i])またはnorm(x[i],p)再帰的に呼び出すかどうかです。 どちらも潜在的に有用な動作です。 前者の方が一般的であるため、私は前者に傾倒します— x[i]は、pノルムではなく、 normのみを定義する任意のノルムベクトル空間である可能性があります。 norm再帰的に呼び出すことは、 vecnormが現在行っていることでもあるため、 vecnormをnormに非推奨にすることと一致しています。

@jebej 、マスターと0.6の両方でdotは、複雑な配列で機能します。たとえば、 dot([3im],[4im])は12+0im $を正しく返します。

norm(matrix)をフロベニウスの標準に変更することのもう1つの良い点は、はるかに安いことです。 norm(A-B)を使用して、2つの行列の違いがどれほど大きいかを把握するのが一般的ですが、ノルムの特定の選択についてはあまり気にしないでください。ただし、多くのユーザーは、現在のデフォルトに気付かないでしょう。 norm(matrix)では、SVDを計算する必要があります。

いくつかの主要なポイントの周りにコンセンサスが形成されるのを見るのは素晴らしいです！ :)（誰かが私を殴る（帯域幅がある場合はやってください！）か、アルファタグが前にヒットしない限り、＃26997を出荷した後、現在のコンセンサスポイントの実装を行います。）ベスト！

将来の参照のための別のリンク： https ：//math.stackexchange.com/a/476742

ここで意識的に採用されている貧弱な命名と、単一の心によって課された貧弱な決定を説明するため。 内積と内積は、異なる数学的特性を持っています。 あなたは数学の文献でよく知られていることに反対してコミュニティ全体を強制しています。

そして将来の読者のために、私たちが集合的な決定を下した場合、代わりに何をすべきだったか：

# make dot what it is, a NOTATION
⋅(x::AbstractVector, y::AbstractVector) = sum(x[i]*y[i] for i in indices(x))

# replace the name dot by the more general inner
inner(x, y) = # anything

ℝⁿ以外の内積に「ドット積」という用語を使用するのは、宇宙で最初の人になると思います。 このイノベーションを世界に押し付けるために、このスレッドに（主に他の開発者を脅迫することによって）自分の意志を押し付けることができたのは良いことです！ ドット積が単なる「表記」に追いやられることはなくなります。代わりに、内積を意味する記号になります（すべての人が知っているように、記号に意味を割り当てることは「表記」の反対です）。

非常に良い意思決定：clap：それは間違いなくコンセンサスでした。 上記のコメントを読むと、誰もがどのように同意したかがわかります。 ：+1：

または、それがどのようにコンセンサスであったかを非常に明確にするために、いくつかのコメントを引用する必要があります。

>>

右-vecdotはinnerに名前を変更できます

@andyferrisによる

オプション2（おそらくより良い）：より数学的に正しい名前を使用する

内側
寸法
しかし、規範をどうするか？

@Jutho

私は同意します、vecdotの代わりとして、新しいメソッドinnerを導入することができます

@Jutho

また、vecdotの名前は奇妙だと思います。実際、それが存在することすら知らず、そのために独自の関数を作成していました...innerと呼ばれます。

@jebejによって

などなど...

人々は互いに声高に議論し、多くの意見の不一致を提起することができますが、それでも説得され、賛否両論のバランスをとることによって（必ずしも全会一致ではありませんが）コンセンサスに到達します。 （ここに各オプションの長所と短所の両方があることに同意します。）ここで（暫定的に！）ゲル化しているように見える結果があなたが好んだ結果ではないことを残念に思いますが、あなたがどう思うかわかりません私は自分の意志を「押し付けた」。

（もちろん、最終的な決定が下されたわけではありません。PRさえまだありません。ましてや、何もマージされていません。）

言語の聴衆に基づいて決定を下せたらいいのにと思います。 誰かがJuliaをツールとして選んだ場合、その人は少なくともinner製品という用語を聞いたことがあると思います。 これは非常に人気のあるコンセプトであり、エキゾチックとはほど遠いものです。 エキゾチックなものには、「永続的なホモロジー」、「量子論」などがありますが、これはあまり普及しておらず、この種の用語を含めることには反対です。

結局のところ、私は科学計算や数学などに最適な言語が欲しいだけです。

@juliohm 、すべての議論は、聴衆が誰であるかというニーズに基づいており、私たち全員がジュリアを可能な限り優れた言語にしようとしています。 数学はつづりを決定しないので、合理的な人々は用語について異なる結論に達する可能性があります。

まず、前述のように、 @ stevengjの現在の提案に確かに同意し、内積の一般名としてdotに固執することができます。 また、私はこの議論の進め方が嫌いであり、確かに正しく引用されたいと思います。 @juliohm 、あなたが私に帰する2番目の引用は私のものではありません。

そうは言っても、賛否両論を考慮した思考の糧として、以下のことを述べたいと思います。 以下は主に短所ですが、@stevengjが言及した長所に同意します。 dotがsum(x[i]*y[i] for i ...)を意味するだけの場合、別のユースケースが簡単に存在する可能性があります。 中置ドット表記が数学で最もよく使用される場合、これは確かに通常は意味です。 内積として、中置ドット表記は通常（確かに排他的ではありませんが）実際のベクトル空間用に予約されています。 他のユースケースには、 σ ⋅ nのようなものをパウリ行列のベクトルσとスカラーのベクトルnで有効にすることが含まれます。 これは、他のスレッドで指摘されたように、 dotが現在実装されている方法の背後にある動機の1つでした。 BLASが実際のベクトルにdotのみを使用し、複素数ベクトルにdotuとdotcを区別することを決定したという事実は、考慮すべきもう1つの問題です。 BLASのバックグラウンドを持つ人々は、複雑なベクトルを使用して、真の内積（つまり、 dotc ）が必要なときにdot(conj(u),v)またはdot(u,v)を計算するかどうか混乱する可能性があります。 さらに、彼らは最初に手元のベクトルの共役コピーを作成せずにdotuを実行する方法を探すかもし​​れません。

@Jutho引用はあなたのものです、あなたの完全なコメントは以下にコピーされます：

私は、vecdotの代わりに、新しいメソッドinnerを導入できることに同意しますが、vecnormを「置き換える」ための適切な名前がわかりません。 実際、私は、悪いベクトルノルムが、私たちが望む操作の十分に確立された明示的な用語であるというvecnormを見つけません。

いずれにせよ、引用は、私たちがこの主題について考えるとき、ここで多くの人の願望が何であるかを示すことを目的としています（少なくとも最初の自然な考えとして）。 あなたが時間の経過とともにあなたの欲求を変えたなら、それは別の話です。 私自身、ヒルベルト空間を使ったモデリング中に「ドット」という用語を頭から浮かび上がらせることは決してありませんでした。 それは不自然で、私が学んだことと矛盾しているように感じます。

@Jutho ：さらに、彼らは最初に手元のベクトルの共役コピーを作成せずにdotuを実行する方法を探すかもし​​れません。

dotu関数をエクスポートする可能性が時々出てきました（例えば＃8300を参照）。 これが時々有用な関数であることに同意します。複雑なベクトル空間に対しても対称双線形（半双線ではない）形式である非共役ユークリッド「内積」（実際には内積ではありません） dotu(x,y) == dotu(y,x) （共役ではありません） 。 しかし、その操作の有用性はℂⁿに限定されません。たとえば、この種の積は、対称性の結果としてマクスウェルの方程式の無限次元ベクトル空間（関数）に現れることがよくあります（基本的に、典型的な損失のある材料のマクスウェル演算子は「複素対称行列」に類似—非共役「内積」の下で対称）。 したがって、 dot(x,y)を一般的なユークリッド内積（最初の引数が共役である）として定義する場合、任意のベクトル空間で非共役ユークリッド積に対してdotu(x,y)関数を定義するのは非常に自然です。それが理にかなっているところ。 ただし、 dotu関数がdotに対する引数として機能する可能性はありません。 ほとんどの場合、複雑なベクトル空間で作業しているときは共役積が必要なので、これが正しいデフォルトの動作です。

しかし、1つの可能性は、現在マスター（0.6ではない）で定義されている方法であるdot(x,y) = sum(x[i]'*y[i] for i = 1:length(x))を定義し、 inner(x,y)を真の内積として定義することであることに同意します。 これには、両方の機能を提供できるという利点があり、どちらも特定の場合に役立つことがあります。 ただし、行列の配列を除いてほとんど常に一致する2つの関数があり、どちらを使用するかを決定するのは少し混乱するでしょう。 多くの人はinnerを意味するときにdotと書き、ほとんどの場合は問題なく機能しますが、行列の配列が渡されると、コードは予期しないことをします。 私の疑惑は、99％の場合、人々は真の内積を望んでおり、実際に必要な場合は、「製品の合計」バージョンをパッケージに残すことができるということです（ sumを呼び出すだけではありません）。 ）。

@juliohm 、名前がそれぞれの引用符の上（下ではなく）にあると思ったので、あなたの投稿を読み間違えました。したがって、 @jebejの引用符を私に帰したと思いました。 申し訳ありません。

@stevengj 、私は確かにdot(x,y) = sum(x[i]'*y[i] for i = 1:length(x))を妥当なデフォルトとして持つことを考えていませんでした。 σ ⋅ nのような場合、最初または2番目の引数の複素数/エルミート活用は不要です。 つまり、私が言っていたのは、科学式で中置ドット表記が使用されている多くの（実際にはすべてではない）場合、その意味はdotuと一致します。つまり、活用なしのsum(x[i]*y[i] for i = 1:length(x))でもあります。実際のベクトル空間の内積として、またはより一般的な構造として。

したがって、私が代替案を作成する場合（必ずしもそれを提唱しているわけではありませんが）、2つの機能を持つことになります。

• dot(x,y) = sum(x[i]*y[i] for i...)は、実際のベクトルの正しい内積です（これは、内積という用語にあまり詳しくない、またはよく知らない人々のユースケースである可能性があります）が、 σ ⋅ nのようなより一般的な構造も可能にします。

• inner(x,y)は常に有効な内積であり、活用と再帰があり、より一般的な技術的なコンテキストで人々が使用します。

私はこれをJulia言語で採用するのに適した選択として擁護していませんが、これが多くの文献で使用されている方法だと思います。 中置ドットが使用される場合、それは実際のベクトルのコンテキストでの内積として、または単に収縮を意味するいくつかのより一般的な構造のいずれかとして使用されます。 任意のベクトル空間に関する一般的な内積が意図されている場合、ほとんどの科学文献（ただし、確かに反例を示しています）は<u,v>または<u|v>に切り替わります（最初の表記では、まだ議論があります） 2つの引数のうちの1つが共役です）。

私はこの提案で生きることができましたが、一般的な内積としてdotしかないことでも同様にうまく生きることができました。 結局のところ、それは優れたドキュメントを持っていることの問題であり、私も誰もがこの「デザイン」の選択につまずくとは信じられません。

@Jutho 、私はdotを単に収縮を意味するように定義することは珍しくないことに同意します。 確かに、両方の方法で例を見つけることができます。 たとえば、プログラミング言語や人気のあるライブラリでは、次のようになります。

• 非共役：Numpy dot （そして、奇妙なことに、 inner ）、MathematicaのDot 、Maxima . 、BLAS dotu

• 共役：Matlabのdot 、FortranのDOT_PRODUCT 、MapleのDotProduct 、PetscのVecDot 、Numpy vdot 、BLAS dotc （ Fortran 77でのオーバーロードにより、これをdotと呼ぶことができなくなりました）、Eigenのドット

一方では、共役内積は通常、複雑なベクトルへの「ドット積」概念の「自然な」拡張として教科書に導入されます。非共役バージョンは、ある意味で「不自然な」拡張であり、通常はそうではありません。あなたが欲しいもの。 （標準ライブラリで共役dot関数を提供する言語（Matlab、Fortran、Julia、Maple）のうち、Mapleのみが非共役バリアントを提供し、需要がないことを示唆しているという事実を考慮してください。）一方、非共役dotu関数は、特定の特殊なケース（上記で説明したものの一部）では（補足として）便利です。

dotとinnerの両方がある場合、コードにinnerを本当に必要としているときに、誤ってdotを使用してしまう人が多いのではないかと思います。ジェネリック。 （Numpyのinnerは、まさにそのような事故のために結合されていないに違いありません。実際のアレイを念頭に置いて実装し、変更するには手遅れになるまで複雑なケースについて考えなかったため、追加しました。厄介な名前のvdot 。）一方、 dotと（おそらく） dotuがある場合、 dotがデフォルトの選択であり、 dotuであることがより明確になります。

（ ⟨u,v⟩ 、 ⟨u|v⟩ 、または(u,v)は、任意のヒルベルト空間の内積のより一般的な表記法であることに同意します。これらは私が通常使用するものですが、これらの表記法はJuliaの初心者ではありません。Unicodeブラケットを関数/マクロ呼び出しとして解析することについての議論がありました。たとえば、＃8934や＃8892などですが、どこにも行きませんでした。これがすぐに変わる可能性は低いようです。）

私はあなたの評価@stevengjに完全に同意します。

私も。

私たちの1人が、PRでどちらかの実装を試して、それがどのように機能するかを確認するときが来たのではないかと思います。

@Jutho私はいつも、パウリ行列を使用した内積を、高次テンソルの収縮の省略形として見ていました...ベクトル空間の1つは、実数の3Dです。

⟨u、v⟩、⟨u| v⟩、または（u、v）は、任意のヒルベルト空間の内積のより一般的な表記法であることに同意します。これらは私が通常使用するものですが、これらの表記法はJuliaの初心者ではありません。

⟨u,v⟩を機能させることは実際には可能です。

@StefanKarpinski ：⟨u、v⟩を機能させることは実際には可能です。

絶対に、そしてこの正確な表記法をサポートすることは＃8934で提案されましたが、それはどこにも行きませんでした。 （山かっこには他の一般的な用途があることにも注意してください。たとえば、⟨u⟩はある種の平均を表すことがよくあります。）これは壊れることはなく、ある時点で追加される可能性がありますが、近くで期待するのは合理的ではないようです。学期。 また、 \langle<tab> x, y \rangle<tab>と入力するのは非常に遅いため、基本操作のプログラミングの観点からはあまり便利ではありません。

<>をオーバーロードすることはできませんよね？

番号

この巨大なスレッドに関するすべてのコメントを読んだとは言えませんが、いくつかのポイントを強調したいと思います。そのうちのいくつかは以前に作成されたものです。

• ドットとインナーを区別することは、過度に衒学的に思えます。 確かに私の耳には、フランス語には「スカラー積」という1つの用語しかなく、私にとって同じ名前のものを区別するのは難しいため、無意味に思えます;-)
• numpyから来て、複雑な配列で作業している場合、デフォルトでdotを共役にすることは、これまでで最高のことです。 ここに決定点はありません。これらのconj(dot())を実行する必要がなくなったことを嬉しく思います。
• ほとんどの場合同じ動作をするが時々異なる2つの関数を持つことは悪い設計であり、ユーザーがよくわからないという理由だけで、一方を実際に呼び出しているはずのコードがもう一方を呼び出すという混乱を引き起こします。 これは特にnormで厄介です。最適化アルゴリズムをコーディングしていて、 norm(delta x) < epsのたびに停止したい場合は、 normと記述します。 しかし、次に、画像などを最適化する必要があります。コードを実行すると、突然、大きな配列の（BLASのために）殺せないSVDが起動します。 これは学術的なものではなく、Optim.jlで問題を引き起こし、他のパッケージでも問題が発生していることは間違いありません。 $＃$ 5 $＃$を探す特別な理由がない限り、誰もvecnormが存在することを知りません。
• 前のポイントに基づいて、 dotとvecdot 、およびnormとvecnormをマージするソリューションは、配列の場合。 規範については、複数の規範が定義されているもの（行列など）を操作するときに、ユーザーが望むのは、特にどれを気にせずに、規範を取得するためにnormを呼び出すことです。 誘導されたノルムは、計算が困難なため、ほとんどの場合、実際的な関心よりも理論的な関心があります。 また、2D-array-as-storageの解釈ではなく、2D-array-as-operatorの解釈に固有です（イメージは2D配列ですが、有用な意味での演算子ではありません）。 それらを計算する可能性があるのは良いことですが、それらがデフォルトのnormになるに値するわけではありません。 合理的でシンプルで十分に文書化されたデフォルトで、発見可能な代替案がある場合は、巧妙さを試みるよりも優れています（ユーザーが巧妙なことをしたい場合は、明示的に実行させてください）。

したがって、 @stevengjの+1

はい、この変更を行う場合、必要なのはドットとノルムだけだと思います（これは、任意の次元の配列または配列の配列に対する再帰的なユークリッド演算ですが、ノルムの場合は、norm（x、p）も次のように定義します。 p-norm）とopnormであり、vecdotまたはvecnormはもうありません。

norm / opnormのより「ジュリアン」な代替手段は、 normがopnormを実行する2D配列をラップできるOperatorタイプを持つことです。 これは、パッケージのレベルで実行できます（そのうちのいくつかはすでに存在します）

norm(Operator(matrix)) opnorm(matrix)と入力したい…

ここのピーナッツギャラリーからチャイムを鳴らして、これがどこに行くのかが好きだと言います— vecnormとvecdotはいつも私を悩ませてきました。 常に私にはかなり専門的であるように思われる演算子ノルムを明示的に要求する必要があることは、計算がはるかに高速で簡単なノルム（たとえばフロベニウスノルム）を要求する必要があるよりもはるかに賢明なようです。 opnorm書くことは、比較的専門的な演算子の規範を求めるための優れたインターフェースのように思えます。

また、 dotとinnerを微妙に区別すると、混乱や横行する誤用につながる可能性が高いと感じています。 両方の機能が必要なことを実行し、一方の機能が簡単な場合に、どちらの機能を使用するかについてユーザーに説明すると、うまく機能しない傾向があります。 私の印象では、ジェネリックコードでは、真の内積⟨u,v⟩が実際に存在するときに、 sum(x*y for (x,y) in zip(u,v))が実際に必要なものになることは比較的まれです。 それが本当に求められているのであれば、それを計算するためにそのようなものを書くだけで、かなり簡単で、明確で、効率的です（Juliaがそれであるため）。

u⋅v関数dotとinnerのどちらで呼び出すかは、これらすべての中で最も重要でない部分のようです。 どちらの選択も歴史家によって災害として振り返られることはないと私はかなり確信していますが、歴史家がまったく気にかけるという考えは確かにお世辞です。 一方では、 u⋅vの「真の内積」の意味を維持することに同意する場合は、はい、 innerがより正確な数学用語です。 一方、対応する関数名を持つ構文がある場合、名前が構文と一致すると、ユーザーの混乱が少なくなる傾向があります。 ここでの構文はドットを使用しているため、その経験則では、この操作のスペルをdotとしてサポートしています。 おそらく、これはconst dot = innerを定義し、両方をエクスポートするための合理的なケースかもしれませんか？ そうすれば、同じ名前なので、好きな名前を使用または拡張できます。 誰かがどちらかの名前を他の何かに使用したい場合、他の名前はデフォルトの意味で引き続き使用できます。 もちろん、同じ関数に対して3つのエクスポートされた名前（ dot 、 inner 、 ⋅ ）が作成されますが、これは少し過剰に思えます。

⋅記号を削除するか、 <u,v>に置き換えるオプションですか？

コメント：

• それは意図を明確にします。 次の2つの例を比較してください。

<u,v> * M * x

対。

u ⋅ v * M * x

• <u,v>構文は、関連付けを意味します。最初にuとvを操作し、次に式の残りの部分を操作します。

• ユーザーが<u,v>と入力しようとした場合、単純なsum(x[i]*y[i])を念頭に置いていた可能性はほとんどありません。 記号⋅は目でスキップしやすく、他にも多くの意味があります。 特に、線形代数では、体F上のベクトル空間Vの場合、スカラーα ∈ Fとベクトルv ∈ Vの積は、さまざまな教科書でα ⋅ vと表されます。

• ⋅を削除または置換すると、複数の名前がエクスポートされる問題も解消されます。 一般的な内積の場合innerと<,>のみをエクスポートする必要があり、反復可能な合計セマンティクスに一致する配列のデフォルトの実装を使用します。

• 体F上のベクトル空間Vに対して上記のようなスカラーごとの積を定義する必要がある場合、彼/彼女はそれに対して⋅表記を定義することができます。 次に、ベクトル空間は素敵な短い構文で完全に定義され、さらに<u,v>を定義することでヒルベルト空間に拡張できます。

構文<u,v>を使用することは絶対にできません。 使用できる構文は⟨u,v⟩です。Unicode角かっこに注意してください。大なり記号ではなく、 <と>です。 また、内積または内積のいずれかであるものの構文としてu'vがありますか？ （どちらかわかりません...）

はい、申し訳ありませんが、Unicodeバージョンです。 読むのは非常に明確でしょう。 また、複数の名前でこの問題を解決し、他の目的のために⋅を解放します。

⋅を他の目的に使用したくないと思います。混乱するようです。

次のようなコードを記述できるとしたら、どれほど素晴らしいことか想像してみてください。

⟨α ⋅ u, v⟩ + ⟨β ⋅ w, z⟩

抽象ベクトル（または型） u,v,w,z ∈ Vおよびスカラーα, β ∈ Fの場合。

u'vは、行列などではなく、1次元配列のみの内積（および共役規則に従う場合は内積）です。 （これは、中置ドットを1d配列に制限することが無意味であるもう1つの理由です。これは、その場合の簡潔な表記法がすでにあるためです。）

ステファン、「正しい数学用語」はカテゴリエラーです。数学的な正確さは、用語や表記法に適用される概念ではありません。 （「正しい」を「従来の」に置き換えます。しかし、そうすると、懸念はそれほど緊急ではなくなります。）

その他のユースケース： https ：//stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

そして、 ⟨,⟩表記を使用したブール内積の正式な導出： https ：//arxiv.org/abs/0902.1290

編集：紙へのリンクを修正

アングルブラケット構文の提案についてどう思いますか？ ここで提起された問題は解決しますか？

それで、あなたの提案は正確には何ですか？ 大まかにこれですか：

1. dotをinnerに非推奨
2. u⋅vを⟨u,v⟩に非推奨

では、 dot関数も⋅演算子もありませんか？

その変更は合理的なものでしょうか？

返信が遅れて申し訳ありませんが、インターネットへのアクセスが制限されている会議に参加しています。

そして、明確さと完全性のために、ここでの反対提案は何ですか？ 何もしない？

提案をさらに明確にするために、関連する意味変化があります：一般化された内積。

注意：これについては、0.7-alphaにならない本当のリスクがあるところまで議論しました。 これは、アルファ版の後で変更できないという意味ではありませんが、その後は変更することに抵抗があります。

はい、ずっと前にPRを提出したスキルがあればいいのにと思います。 それを実現することは、非常に重要な機能であるとは思いますが、私の能力を超えています。

演算子の構文の質問を無視しても、セマンティック概念の各セット（現在のdotとvecdotおよび現在のnormとvecnorm ）。

dot側の場合、オプションのスペース全体（ここでも割引演算子）は次のようになります。

I. 0.7の動作を標準のデプワーンなしの内積に変更することにより、配列のベクトルでdotをサイレントに解除します（ただし、動作が変更されていることを警告できます）。 0.7でもvecdotをdotに廃止します。
II。 0.7では、 innerへのすべての入力でvecdotを廃止します。
III。 0.7では、配列のベクトルのdotをその定義に対して非推奨にし、他の入力のdotと$ innerへのすべての入力のvecdotを非推奨にします。
IV。 0.7では、配列のベクトルのdotとvecdotの両方を、エクスポートされていない関数またはその定義のいずれかに非推奨にし、 dotへの他のすべての入力のvecdotを非推奨にします。 1.0では、内積セマンティクスを持つ配列のベクトルにdotを追加します。

標準側では、単一のパスについていくつかのコンセンサスがあります（0.7では、マトリックスのnormをopnormに非推奨にし、場合によってvecnormをinnernormに非推奨にします;1.0では、現在のvecnormセマンティクスを持つ行列にnormを追加します）が、1.0では追加の名前（ vecnormまたはinnernorm ）になります）; これを回避する方法は、0.7のvecnormを、エクスポートされた名前ではなく、その定義またはBase.vecnormなどのエクスポートされていない関数に対して非推奨にすることです。

...おもう。 私が物事を以前よりももっとムシにしないことを望みます。

コードベースに精通している人は誰でも変更のPRを提出できますか？

誰もが同意しているように見える標準的なものを分割して、少なくともそれを成し遂げることはできますか？ dot対innerビットはかなり物議を醸していますが、そうでない部分をそのスティミーにさせないようにしましょう。

@StefanKarpinski 、それらはある程度結合されていることに注意してください。ドット（内積）積とノルムの両方があるタイプの場合、それらは一貫している必要があります。

わかりました、私はこれがどちらの方向に進むかは本当に気にしません。 仕事をする人は誰でも決めることができます。

vecdotを再帰的にすることで、真の内積（および対応するノルムとしてvecnorm ）として動作させるPR（＃25093）がありました。 これは、将来のdotとnormがどのようになるかを示す出発点として役立つ場合があります。 残念ながら、gitスキルが不足しているため、そのPRを台無しにしてしまい、新しい反復構文が完了した後でPRに戻ることを計画して、PRを閉じました。

ただし、数日前に2回目の父親になったばかりであるということは、現在、私のカレンダーに「空き時間」の時間枠がないことを意味します。

数日前に二度目の父親になったばかり

ジュトおめでとう！ 🎉

はい、おめでとうございます！

dotとinnerの両方を持つという考えについて、いくつかのコンセンサスが形成されているようです。ここで、

1. innerは真の再帰内積です
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x))共役であるかどうかに関係なく、したがってVector{<:Number}またはVector{<:Real}のdotと重複します

それにかんする：

多くの人は、内側を意味するときにドットを記述し、ほとんどの場合は問題なく機能しますが、行列の配列が渡されると、コードは予期しない動作をします。

それが問題になるとは思わない。 これはかなり珍しい操作なので、少なくとも人々がそれが何をするのかを見たり、ドキュメントを見に行ったりすることを期待します。

dotのセマンティクスはほとんどの場合変更されないため、上記は大きな変更であり、それほど混乱を招くことはないと思います。

dotとinnerの両方を持つという考えについて、いくつかのコンセンサスが形成されているようです。

それどころか、 https： //github.com/JuliaLang/julia/issues/25565#issuecomment -390069503からの議論は、たとえばhttps：// githubに示されているように、どちらか一方を使用することを支持しているようですが、両方を使用することはできません。 com / JuliaLang / julia / issues / 25565＃issuecomment -390388230であり、リアクションで十分にサポートされています。

たぶんinner （およびdot ）は再帰的な内積/ドット/スカラー製品である必要があり、古い動作はdotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x))やdotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x))などの関数で実装できます。 ？ dotuおよびdotcという名前は、対応するBLAS名と一致します。

（⟨u、v⟩、⟨u|v⟩、または（u、v）は、任意のヒルベルト空間の内積のより一般的な表記法であることに同意します。これらは私が通常使用するものですが、これらの表記法はJuliaの初心者ではありません。 。Unicodeブラケットを関数/マクロ呼び出しとして解析することについての議論がありました（例：＃8934および＃8892）が、どこにも行きませんでした。これはすぐに変わる可能性は低いようです。）

@stevengj 、この段落を前のコメントに自分で追加したとき、構文⟨u,v⟩を言語で実装するのは難しいということですか？

この機能がJuliav1.0に移行する可能性はありますか？ 一般的な内積の概念に依存するアイデアやパッケージはたくさんあります。 期待を下げる必要があるかどうか教えてください。 いつもリマインダーしてすみません。

＃27401を見たことがありませんか？

@jebejに感謝し、 @ ranochaがリードしてくれてありがとう：heart：

この段落を前のコメントに自分で追加したとき、構文⟨u、v⟩を言語で実装するのは難しいということですか？

パーサーに追加することは技術的に難しいことではありませんが、言語でカスタムブラケットを表現する方法（および表現するかどうか）についてコンセンサスを得るのは難しいことが証明されています。 4年前にはどこにも行かず、それ以来復活していない＃8934の議論を参照してください。 （さまざまな分野で、人々はさまざまなことに同じ括弧を使用しているという事実に加えて、たとえば、⟨u⟩は統計物理学のアンサンブル平均に使用されます。）＃8892で提起された別の問題は、多くの異なるUnicodeの視覚的な類似性です。ブラケット。

@stevengjに感謝します、私は説明に感謝します。 パッケージ全体で標準化された一般的な内積が得られることに、私はすでに非常に興奮しています。 ：100：山かっこ表記は、将来の別のリリースサイクルで輝く可能性があります。 それほど重要ではありませんが、私たちの出版物の数学のような文字通りのコードを書くことができるのは非常に便利です。

⟨args...⟩がanglebrackets演算子などを呼び出すための有効な構文である場合（この構文が呼び出す関数を呼び出すには、前例がないため、実際には少し注意が必要です）。構文に必要な意味を選択します。

@StefanKarpinski 、＃8934の議論は、それはマクロであるべきだというものでした。 合意に達したとは思いません。

（Baseでanglebrackets(a,b)がinner(a,b)を意味すると決定した場合、決定はすでに行われているため、人々が「好きな意味を選択する」ことを思いとどまらせます。
もちろん、それはひどい選択ではありませんが、解析されている限り、Baseでこれに意味を割り当てる必要はないかもしれません。）

その議論の詳細は思い出せませんが、マクロを作成することは私には明らかに悪い考えのように思えます。

＃27401では、内積が真剣に受け止められていると考えられます。

従来、問題は、関連するPRがマージされた場合にのみクローズされます...

もちろん、開いたままにしておくこともできます。 トリアージラベルから外したかっただけです。

＃27401がマージされたので、これを閉じる必要がありますか？