+1

または、糖衣構文としてfunc.(args...)

broadcast(func, args...)

しかし、多分私はそれを好む唯一の人ですか？
いずれにせよ、+ 1。

：-1：どちらかといえば、ステファンの他のf[...]の提案は、理解と非常によく似ていると思います。

@ihnortonのように、私もこのアイデアがあまり好きではありません。 特に、 a .+ bとsin.(a)の両方を持つという非対称性は嫌いです。

たぶん、特別な構文は必要ありません。 ＃1470で、私たちは次のようなことをすることができます

call(f::Callable,x::AbstractArray) = applicable(f,x) ? apply(f,x) : map(f,x)

正しい？ おそらく、これは魔法のように思えますが、どの関数でも自動マップを取得することはできません。

@quinnjその1行は、呼び出しのオーバーロードを許可することについての私の最大の恐れを要約しています。 私は何日も眠ることができなくなります。

構文的に可能かどうかはまだわかりませんが、 .sin(x)どうでしょうか。 それはa .+ bにもっと似ていますか？

[]は過負荷になりすぎており、この目的には機能しないと思います。 たとえば、おそらくInt(x)を記述できますが、 Int[x]は配列を作成するため、 mapを意味することはできません。

私は.sin(x)で搭乗します。

そのためにいくつかの構文をクローバックする必要がありますが、 Int(x)がスカラーバージョンである場合、 Int[x]は、要素タイプIntのベクトルを構築するための類推によって合理的です。 私の考えでは、その構文をより一貫性のあるものにする機会は、実際にはf[v]提案の最も魅力的な側面の1つです。

mapのf[v]構文を作成すると、構文の一貫性がどのように向上しますか？ わかりません。 mapは、現在のT[...]配列コンストラクター構文とは異なる「形状」を持っています。 Vector{Int}[...]どうですか？ それはうまくいきませんか？

笑、怖い@JeffBezansonごめんなさい！ ははは、呼び出しのオーバーロードは確かに少し怖いです。たまに、ジュリアで実行できるコードの難読化の種類について考えますcallを使用すると、厄介なことを実行できます。

.sin(x)もいい考えだと思います。 マルチ引数をどうするかについてのコンセンサスはありましたか？

：-1:。 高階関数を使用する場合と比較して、2文字を節約することは、読みやすさのコストに見合う価値はないと思います。 .func() / func.()とfunc()がいたるところに散在しているファイルを想像できますか？

少なくとも、とにかくa.(b)構文を削除する可能性があります。

うわー、ミツバチの巣をかき混ぜることについて話してください！ 議論をよりよく反映するために名前を変更しました。

2引数の名前をmapからzipWithに変更することもできます:)

いくつかの構文が本当に必要な場合は、 [f <- b]または括弧の_内側_の内包表記に関する別のしゃれはどうですか？

（ @JeffBezanson誰かがCJOSまたはMoose.jlを書くのではないかと心配しています:) ...その機能を利用できる場合は、マニュアルのDon't do stupid stuff: I won't optimize thatセクションに入れてください）

現在Int[...]と書いている場合は、要素タイプIntの配列を作成していることを示しています。 ただし、 Int(x)がIntを関数として適用して$ xをIntに変換することを意味する場合、 Int[...]は「 Intを適用する」を意味すると考えることもできます。 Intの値が生成されます。 したがって、 Int[v]と書くと[ Int(x) for x in v ]に相当し、 Int[ f(x) for x in v ]は[ Int(f(x)) for x in v ]に相当します。 もちろん、そもそもInt[ f(x) for x in v ]を書くことの有用性の一部を失っています。つまり、要素タイプがIntであることを静的に知ることができますが、それを強制するとInt(x)はタイプIntの値を生成する必要があります（不合理な制約ではありません）。そうすれば、そのプロパティを回復できます。

より多くのベクトル化/暗黙の猫の地獄として私を襲います。 Int[x, y]は何をしますか？ さらに悪いことに、 Vector{Int}[x] ？

私はそれがこれまでで最高のアイデアだと言っているわけでも、それを支持しているわけでもありません。それ自体がちょっとしたハックである既存の使用法と_完全に_衝突しないことを指摘しているだけです。 既存の使用法をより一貫性のあるパターンの一部にすることができれば、それは勝利です。 f[v,w]が何を意味するのかわかりません。明らかな選択肢は、 [ f(x,y) for x in v, y in w ]またはmap(f,v,w)ですが、まだまだ選択肢があります。

a.(b)はほとんど使われていない気がします。 クイックテストを実行しました。これは、野生の〜4,000のjuliaソースファイルのうち54でのみ使用されています： https：//gist.github.com/jakebolewski/104458397f2e97a3d57d。

完全に衝突すると思います。 T[x]の形状はT --> Array{T}で、 mapの形状Array{T} --> Array{S}です。 それらはほとんど互換性がありません。

これを行うには、 Vector{T}のコンストラクターとしてT[x,y,z]をあきらめる必要があると思います。 Iがベクトルである、単純な古い配列インデックスA[I]は、 map(i->A[i], I)と見なすことができます。 配列の「適用」は、関数の適用に似ています（もちろん、matlabはそれらに同じ構文を使用します）。 その意味で、構文は実際に機能しますが、その過程で型付きベクトル構文が失われます。

ここで構文を議論することは、より重要な変更、つまりmap高速化することから気をそらすような気がします。

明らかに、 mapを高速化すること（ちなみに、これは、ジュリアの関数の概念のかなり徹底的な再設計の一部である必要があります）がより重要です。 ただし、 sin(x)からmap(sin, x)に移行することは、ユーザビリティの観点から非常に重要であるため、ベクトル化を実際に停止するには、構文が非常に重要です。

ただし、sin（x）からmap（sin、x）に移行することは、ユーザビリティの観点から非常に重要であるため、ベクトル化を実際に停止するには、構文が非常に重要です。

完全に同意しました。

f[x]は、現在の型付き配列構造Int[x, y]などとほとんど一致しないという@JeffBezansonに同意します。

sin.よりも.sinを好むもう1つの理由は、最終的にBase.(+)を使用して$＃ Baseの+関数にアクセスできるようにすることです（1回はa.(b)は削除されます）。

モジュールが独自のsin （またはその他の）関数を定義し、その関数をベクトルで使用したい場合、 Module..sin(v)を実行しますか？ Module.(.sin(v)) ？ Module.(.sin)(v) ？ .Module.sin(v) ？

これらのオプションはどれも、もはや本当に良いようには見えません。

この議論は問題の本質を見逃しているように感じます。 つまり、単一の引数関数をコンテナにマッピングするとき、 map(func, container)構文は_すでに_明確で簡潔であるように感じます。 代わりに、カリー化のためのより良い構文から利益を得ることができると私が感じるのは、複数の引数を扱うときだけです。

たとえば、 map(x->func(x,other,args), container)の冗長性を取り上げるか、フィルター操作を連鎖させてfilter(x->func2(x[1]) == val, map(x->func1(x,other,args), container))を悪化させます。

このような場合、マップ構文を短くしてもあまり役に立たないと思います。 これらは特に悪いとは思いませんが、a）簡単なmapはあまり役に立たないと思います。また、b）Haskellの構文の後にピン留めするのが大好きです。 ;）

IIRC、Haskellでは、上記はfilter ((==val) . func2 . fst) $ map (func1 other args) containerと書くことができますが、引数の順序をfunc1に少し変更します。

elmでは.funcはx->x.funcで定義され、これは非常に便利です。elmレコードを参照してください。 mapでこの構文を使用する前に、これを考慮する必要があります。

私はすきです。

ジュリアでは、多くの言語ほどフィールドアクセスはそれほど重要ではありませんが。

はい、ジュリアのフィールドは「プライベート」な用途に向いているため、ここではあまり関連性がないと感じています。 しかし、フィールドアクセスのオーバーロードについての進行中の議論により、それはより賢明になるかもしれません。

$＃$ .+の非対称性がなければ、 f.(x)は問題の少ない解決策のように見えます。 しかし、 .と「要素ごとの操作」のシンボリックな関連付けを維持することは、私見としては良い考えです。

現在の型付き配列構造が非推奨になる可能性がある場合は、 func[v...]をmap(func, v...)に変換し、リテラル配列を（現在のT[a1, ..., an]の代わりに） T[[a1, ..., an]]と書くことができます。 T[a1, ..., an] ）。

sin∘vも静かで自然だと思います（配列vがインデックスから含まれる値へのアプリケーションである場合）、またはもっと単純にsin*vまたはv*[sin]' （ *(x, f::Callable) ）などを定義する必要があります。

新鮮な心でこの問題に戻ると、 f.(x)は非常に自然な構文と見なすことができることに気付きました。 f.および(として読み取る代わりに、 fおよび.(として読み取ることができます。 .(は、比喩的には(関数呼び出し演算子の要素ごとのバージョンであり、$ .+やその仲間と完全に一致しています。

.(が関数呼び出し演算子であるという考えは、私を非常に悲しくさせます。

@johnmyleswhite詳しく説明しますか？ 私は構文の直感性、または他の言語との視覚的な一貫性について話していましたが、技術的な実装についてはまったく話していませんでした。

私にとって、 (は言語のセマンティクスの一部ではなく、構文の一部にすぎません。 したがって、 .(と(が異なって開始する方法を発明する必要はありません。 前者はcall Expr $の代わりにmulticall Exprを生成しますか？

いいえ。私が言ったように、私はまったく暗示していませんでしたが、2つの異なる呼び出し演算子が必要です。 要素ごとの操作のための_視覚的に_一貫した構文を見つけようとしているだけです。

私にとって、これらのオプションを殺すのは、マルチ引数関数をどのようにベクトル化するかという問題です。 それを行う単一の方法はありません。すべての可能な方法をサポートするのに十分一般的なものは、私たちがすでに持っている多次元配列内包に非常によく似ています。

複数の引数mapがすべての引数を反復処理することは、非常に標準的です。
これを行うと、マップを呼び出すための。（構文が作成されます。その構文は次のようになります。
いろいろな理由でそれほど素晴らしいとは言えませんが、私はこれらの面で大丈夫でしょう。

複数引数関数に対していくつかの一般化が可能であるという事実は、少なくともいくつかの特殊なケースをサポートすることに反対する議論にはなり得ません。テンソルに対していくつかの方法で一般化できる場合でも、行列転置が役立つのと同じです。

最も有用なソリューションを選択する必要があります。 可能な選択肢については、 https ：//github.com/JuliaLang/julia/issues/8389#issuecomment -55953120（および以下のコメント）ですでに説明されています。 @JeffBezansonが言ったように、 mapの現在の振る舞いは合理的です。 興味深い基準は、 @vectorize_2argを置き換えることができることです。

私のポイントは、 sin.(x)とx .+ yが共存するのは厄介だということです。 .sin(x) -> map(sin, x)とx .+ y -> map(+, x, y)が欲しいです。

.+は実際にはbroadcastを使用します。

純粋な絶望からのいくつかの他のアイデア：

1. コロンをオーバーロード、 sin:x 。 複数の引数にうまく一般化されていません。
2. sin.[x] ---この構文は使用可能ですが、現在は意味がありません。
3. sin@x ---利用可能ではありませんが、おそらく可能です

私はこれが必要だとは本当に確信していません。

私もダメ。 ここではf.(x)が最適なオプションだと思いますが、私はそれが好きではありません。

しかし、これがなければ、あらゆる種類のベクトル化された関数、特にint()のようなものの作成を回避するにはどうすればよいでしょうか。 これが、 https：//github.com/JuliaLang/julia/issues/8389でこのディスカッションを開始するきっかけになりました。

map(func, x)の使用を推奨する必要があります。 タイピングはそれほど多くなく、他の言語から来た人なら誰でもすぐにわかります。

そしてもちろん、それが速いことを確認してください。

ええ、でもインタラクティブに使うととても辛いです。 それはRから来る人々にとって大きな迷惑になるでしょう（少なくとも、私は他の言語については知りません）、そして私はこれがジュリアがデータ分析に適していないという感じを与えたくありません。

もう1つの問題は一貫性です。 log 、 expなど、現在ベクトル化されているすべての関数を削除し、代わりにmapを使用するように依頼する場合を除きます（この決定の実用性の興味深いテスト）、言語は一貫性がなくなり、関数がベクトル化されているかどうか（およびどの引数で）を事前に知ることが困難になります。

他の多くの言語は何年もの間mapを使用しています。

すべてのベクトル化を停止する計画を理解したので、ほとんど/すべてのベクトル化された関数を削除することは常に戦略の一部でした。

はい、_course_のすべてをベクトル化するのをやめます。 矛盾はすでに存在しますsin 、 expなどを配列に暗黙的にマッピングする必要があるという説得力のある理由がないため、どの関数をベクトル化するか、またはベクトル化する必要があるかを知ることはすでに困難です。

そして、ライブラリの作成者にすべての適切な関数に@vectorizeを置くように指示するのはばかげています。 関数を書くことができるはずです。誰かがすべての要素についてそれを計算したい場合は、 mapを使用します。

一般的に使用されるベクトル化された数学関数を削除するとどうなるか想像してみましょう。

1. 個人的には、 exp(x) map(exp, x)を書いてもかまいませんが、後者は少し短くてきれいです。 ただし、パフォーマンスには_大きな_違いがあります。 ベクトル化された関数は、私のマシンのマップよりも約5倍高速です。
2. 複合式を使用している場合、問題はさらに興味深いものになります。 複合式を考えてみましょう： exp(0.5 * abs2(x - y)) 、そして次のようになります

# baseline: the shortest way
exp(0.5 * abs2(x - y))    # ... takes 0.03762 sec (for 10^6 elements)

# using map (very cumbersome for compound expressions)
map(exp, 0.5 * map(abs2, x - y))   # ... takes 0.1304 sec (about 3.5x slower)

# using anonymous function (shorter for compound expressions)
map((u, v) -> 0.5 * exp(abs2(u - v)), x, y)   # ... takes 0.2228 sec (even slower, about 6x baseline)

# using array comprehension (we have to deal with two array arguments)

# method 1:  using zip to combine the arguments (readability not bad)
[0.5 * exp(abs2(u - v)) for (u, v) in zip(x, y)]  # ... takes 0.140 sec, comparable to using map

# method 2:  using index, resulting in a slightly longer statement
[0.5 * exp(abs2(x[i] - y[i])) for i = 1:length(x)]  # ... takes 0.016 sec, 2x faster than baseline 

ベクトル化された数学関数を削除する場合、読みやすさとパフォーマンスの両方で受け入れられる唯一の方法は、配列の理解であるように思われます。 それでも、それらはベクトル化された数学ほど便利ではありません。

-ベクトル化されたバージョンを削除する場合は-1。 実際、VMLやYepppなどのライブラリは、ベクトル化されたバージョンに対してはるかに高いパフォーマンスを提供するため、これらを活用する方法を理解する必要があります。

これらがベースにあるかどうかは別の議論であり、より大きな議論ですが、ニーズは現実的であり、パフォーマンスは私たちが持っているものよりも高くなる可能性があります。

@lindahuaと@ViralBShah ： mapを改善する前に、ベクトル化された関数を削除することを前提としているようですが、誰かがそうすることを提案しているとは思いません。

@lindahuaの例は非常にわかりやすいと思います。ベクトル化された構文は、他のソリューションよりもはるかに優れており、数式に非常に近いものです。 私はそれを失うのはかなり悪いことであり、他の科学言語から来た人々はおそらくこれをジュリアの否定的な点と見なすでしょう。

すべてのベクトル化された関数を削除しても問題ありません（ mapが十分に高速な場合）、それがどのように行われるかを確認します。 その時点で、便利な構文を提供することの関心がさらに明らかになると思います。それが事実であることが判明した場合は、それを追加する時期がまだあります。

Juliaは、インタラクティブな使用（この場合、式が長くなると入力が煩わしい）と数学的な計算（コードを読みやすくするために、数式を数式にできるだけ近づける必要がある）を重視しているため、他の多くの言語とは異なると思います。 これが、Matlab、R、およびNumpyがベクトル化された関数を提供する理由の一部です（他の理由はもちろんパフォーマンスであり、Juliaで解消される可能性のある問題です）。

議論からの私の感じは、ベクトル化された数学の重要性は控えめに述べられているということです。 実際、ベクトル化された数学の主な利点の1つは、式の簡潔さにあります。これは、「forループが遅い言語」の単なる一時的なものではありません。

y = exp(x)との比較

for i = 1:length(x)
    y[i] = exp(x[i])
end

前者は明らかに後者よりもはるかに簡潔で読みやすいです。 Juliaがループを効率的にするという事実は、コードを常にベクトル化解除する必要があるという意味ではありません。これは、私にとっては非常に逆効果です。

私たちは人々が自然な方法でコードを書くことを奨励すべきです。 一方では、これは、複雑なコードを記述したり、ベクトル化された関数をそれらが適合しないコンテキストでねじったりすることを試みるべきではないことを意味します。 一方、最も意味のある場合はいつでも、ベクトル化された数学の使用をサポートする必要があります。

実際には、数式を数値の配列にマッピングすることは非常に一般的な操作であり、面倒にするのではなく、これを便利にするように努力する必要があります。 この目的のために、ベクトル化されたコードは依然として最も自然で簡潔な方法です。 パフォーマンスはさておき、特に複数の引数を持つ複合式の場合、 map関数を呼び出すよりも優れています。

私たちは確かにすべてのベクトル化されたバージョンを望んでいませんが、ベクトル化するために毎回マップを使用することは、Dahuaがちょうど上で述べた理由のために迷惑になるでしょう。

マップが高速であれば、ベクトル化された関数のより小さくて意味のあるセットを持つことに焦点を当てることができます。

私は簡潔な地図表記を支持する側に強く降りてくると言わなければなりません。 私はそれが異なるニーズの間の最良の妥協点だと感じています。

ベクトル化された関数は好きではありません。 何が起こっているのかを隠します。 関数のベクトル化されたバージョンを作成するこの習慣は、ミステリーコードにつながります。 パッケージの関数fがベクトルで呼び出されるコードがあるとします。 関数が何をしているのかをある程度知っていても、それが要素ごとに機能するのか、ベクトル全体で機能するのか、コードを読んでも確信が持てません。 科学計算言語にこれらのベクトル化された関数を持っていた歴史がなかったら、私たちは今それらをほとんど受け入れていないと思います。

また、関数が使用される簡潔なコードを有効にするために、関数のベクトル化されたバージョンを作成するように暗黙的に推奨される状況にもつながります。

何が起こっているかについて最も明確なコードはループですが、 @ lindahuaが言うように、それは非常に冗長になり、特にインタラクティブな使用を目的とした言語では、独自の欠点があります。

これはmapの妥協につながり、理想に近いと思いますが、それでも十分に簡潔ではないという@lindahuaに同意します。

@lindahuaに同意しないのは、前述の理由から、ベクトル化された関数が最良の選択であるということです。 私の推論が導くのは、ジュリアはmapの非常に簡潔な表記法を持つべきだということです。

Mathematicaがその速記法でそれをどのように行うかが本当に魅力的だと思います。 Mathematicaの引数に関数を適用するための省略表記は@なので、 Apply関数fを次のようにベクトルに変換します： f @ vector 。 関数をマッピングするための関連する省略表記は/@であるため、 fを次のようにベクトルにマッピングします： f /@ vector 。 これにはいくつかの魅力的な特徴があります。 両方のショートハンドは簡潔です。 両方が@記号を使用しているという事実は、それらが行うことの間に関係があることを強調していますが、マップ内の/は、マッピング中とマッピング中を明確にするために視覚的に区別できます。そうではありません。 これは、JuliaがMathematicaの表記法を盲目的にコピーする必要があると言っているのではなく、マッピングに適した表記法が非常に価値があるということだけです。

すべてのベクトル化された関数を取り除くことを提案しているわけではありません。 その列車は駅を出てからずっと経ちました。 むしろ、ベクトル化された関数のリストをできるだけ短くし、ベクトル化された関数のリストに追加しないように、簡潔なマップ表記を提供することをお勧めします。

もちろん、これはすべてmapと無名関数が高速であることを条件としています。 現在、ジュリアは奇妙な立場にあります。 科学計算言語では、ループが遅いために関数がベクトル化されていました。 これは問題ではありません。 代わりに、Juliaでは、マップ関数と無名関数が遅いため、関数をベクトル化しました。 ですから、私たちは始めたところに戻っていますが、理由はさまざまです。

ベクトル化されたライブラリ関数には1つの欠点があります。つまり、ライブラリによって明示的に提供される関数のみが使用可能です。 つまり、たとえば、 sin(x)はベクトルに適用すると高速になりますが、 sin(2*x)は、2回トラバースする必要がある中間配列（最初に書き込み、次に読み取り）が必要になるため、突然非常に遅くなります。

1つの解決策は、vectorizABLE数学関数のライブラリです。 これらは、インライン化のためにLLVMで使用できるsin 、 cosなどの実装になります。 LLVMはこのループをベクトル化することができ、うまくいけば非常に効率的なコードにつながる可能性があります。 Yepppは正しいループカーネルを持っているようですが、インライン化のためにそれらを公開していないようです。

パラダイムとしてのベクトル化に関するもう1つの問題は、標準ライブラリによって祝福されているもの以外のコンテナタイプを使用すると、まったく機能しないことです。 これはDataArraysで確認できます。定義している新しいコンテナータイプの関数を再ベクトル化するために使用される、とんでもない量のメタプログラミングコードがあります。

それを@eschnettのポイントと組み合わせると、次のようになります。

• ベクトル化された関数は、標準ライブラリの関数に制限した場合にのみ機能します
• ベクトル化された関数は、標準ライブラリのコンテナタイプに制限した場合にのみ機能します

私のポイントは、ベクトル化された関数を常に保持する必要があるということではなく、ベクトル化された関数を作成するのと同じくらい簡潔な方法が必要であることを明確にしたいと思います。 mapを使用しても、おそらくこれを満足させることはできません。

@eschnettのいくつかの関数に_vectorizable_のタグを付けるというアイデアが好きです。コンパイラーは、ユーザーがベクトル化されたバージョンを明示的に定義しなくても、ベクトル化可能な関数を配列に自動的にマップできます。 コンパイラーは、ベクトル化可能な関数のチェーンを融合ループに融合することもできます。

@eschnettのコメントに触発されて、私が念頭に置いていることは次のとおりです。

# The <strong i="11">@vec</strong> macro tags the function that follows as vectorizable
<strong i="12">@vec</strong> abs2(x::Real) = x * x
<strong i="13">@vec</strong> function exp(x::Real) 
   # ... internal implementation ...
end

exp(2.0)  # simply calls the function

x = rand(100);
exp(x)    # maps exp to x, as exp is tagged as vectorizable

exp(abs2(x))  # maps v -> exp(abs2(v)), as this is applying a chain of vectorizable functions

コンパイラーは、SIMDを使用する機会を特定することにより、計算を（低レベルで）再ベクトル化することもできます。

もちろん、エンドユーザーが@vecを利用できるようにして、ユーザーが自分の関数をベクトル化可能として宣言できるようにする必要があります。

ありがとう、 @ lindahua ：あなたの説明は大いに役立ちます。

@vecは、関数@pureの宣言とは異なりますか？

@vecは、関数を要素ごとにマップできることを示します。

すべての純粋関数がこのカテゴリに分類されるわけではありません。たとえば、 sumは純粋関数であり、_vectorizable_として宣言することはお勧めできません。

$ + $のpure ＃$タグとassociativeタグから$ sumのvecプロパティを、$ reduceの方法に関する知識とともに再現できませんでした。 foldl / foldr 、 pureおよびassociative関数が与えられたときに機能しますか？ 明らかにこれはすべて仮説ですが、ジュリアが型の特性に全面的に取り組むのであれば、関数の特性にも全面的に取り組むことで、ベクトル化の最先端技術を大幅に改善することを想像できました。

新しい構文を追加することは、私たちが望むものとは逆のように感じます（Any []とDictの特別な構文を削除した後）。 これらのベクトル化された関数を削除することの全体的な_ポイント_は、特別な場合を減らすことです（そして、構文は関数のセマンティクスと異なるべきではないと思います）。 しかし、簡潔な地図が役立つことに同意します。

では、簡潔な中置map演算子を追加してみませんか？ ここでは$任意に選択します。 これにより、 @ lindahuaの例は

exp(0.5 * abs2(x - y))

に

exp $ (0.5 * abs2 $ (x-y))

さて、ユーザー定義の中置演算子に対するHaskellのようなサポートしかない場合、これは1行の変更($) = mapなります。 :)

IMO、他の構文提案は既存の構文に視覚的に近すぎるため、コードを調べるときに解析するにはさらに精神的な努力が必要になります。

• foo。（x）-標準タイプのメンバーアクセスと視覚的に類似
• foo [x] -foo配列のx番目のメンバーにアクセスしていますか、それともここでマップを呼び出していますか？
• .foo（x）- @ kmsquireが指摘したように問題があります

そして、 @vecソリューションは、そもそも避けようとしている@vectorizeに近すぎるように感じます。 確かに、＃8297の注釈はいくつかあると便利であり、将来的に役立つ可能性があります。よりスマートなコンパイラーは、これらのストリーム融合の機会を認識し、それに応じて最適化できます。 しかし、私はそれを強制するという考えは好きではありません。

中置マップと高速無名関数も、次のようなことができる場合、一時的なものの作成に役立ちます。

(x, y) -> exp(0.5 * abs2(x - y)) $ x, y

クールな新しいTrait.jlのアイデアは、ベクトル化可能な関数を指定するという文脈で借りることができるのだろうか。 もちろん、この場合、特定の特性を持つjuliaタイプではなく、 Functionタイプの個々の_インスタンス_がベクトル化可能かどうかを確認しています。

さて、ユーザー定義の中置演算子に対するHaskellのようなサポートしかなかったとしたら

6582＃6929十分ではありませんか？

この議論には、可能な限り少ない配列一時で式全体をベクトル化することについてのポイントがあります。 ベクトル化された構文が必要なユーザーは、ベクトル化されたexp(x)だけは必要ありません。 彼らは次のような表現を書きたいと思うでしょう

y =  √π exp(-x^2) * sin(k*x) + im * log(x-1)

魔法のようにベクトル化してもらいます

関数を「ベクトル化可能」としてマークする必要はありません。 これはむしろ、関数がどのように実装され、Juliaが利用できるかという特性です。 たとえばCで実装されている場合は、LLVMオプティマイザが引き続きアクセスできるように、（オブジェクトファイルではなく）LLVMバイトコードにコンパイルする必要があります。 Juliaでそれらを実装することも機能します。

ベクトル化可能性とは、Yepppプロジェクトで非常によく説明されている方法で関数を実装することを意味します。ハードウェアでベクトル命令として使用できる場合は、分岐、テーブル、除算、または平方根はありません。マージ操作。

残念ながら、そのような実装はハードウェアに依存します。つまり、どのハードウェア命令が効率的であるかに応じて、異なるアルゴリズムまたは異なる実装を選択する必要がある場合があります。 私は過去にこれをC ++で（https://bitbucket.org/eschnett/vecmathlib/wiki/Home）、わずかに異なるターゲットオーディエンス（自動ベクトル化ではなく手動でベクトル化されるステンシルベースの操作）で実行しました。コンパイラ）。

ここJuliaでは、（a）コンパイラーがLLVMであることがわかっており、（b）C ++の代わりにJuliaでこれを実装できるため（マクロとテンプレート）、作業が簡単になります。

もう1つ考慮すべきことがあります。それは、IEEE標準の一部を放棄した場合、速度を大幅に向上させることができるということです。 多くのユーザーは、たとえば非正規化数は重要ではないこと、または入力が常にsqrt(max(Double))未満になることなどを知っています。問題は、これらの場合に高速パスを提供するかどうかです。 私はこれに非常に興味があることを知っていますが、他の人は代わりに正確に再現可能な結果を​​好むかもしれません。

ジュリアでベクトル化可能なexpプロトタイプを作成しましょう。 次に、LLVMがループをベクトル化する際にどのように機能するか、およびどのような速度が得られるかを確認できます。

関数の引数を全幅括弧で囲むのは怖すぎますか？

申し訳ありませんが、 @ johnmyleswhiteが上記の特性で機能について話していたのとまったく同じことを繰り返していることに気づきませんでした。 続ける。

@eschnett API（関数がベクトル化可能かどうか）を実装の詳細（関数のコンパイル方法）にリンクするのは合理的ではないと思います。 理解し、時間とアーキテクチャ間で安定性を保つことは非常に複雑に聞こえます。外部ライブラリで関数を呼び出す場合は機能しません。たとえば、 logは、openlibmから関数を呼び出すため、ベクトル化可能として検出されません。

関数の数学的特性を伝達するために特性を使用するというOTOH @ johnmyleswhiteのアイデアは、優れた解決策になる可能性があります。 （ @lindahuaの提案は、私がしばらく前に提案した機能ですが、トレイトを使用するソリューションはさらに優れている可能性があります。）

さて、ユーザー定義の中置演算子に対するHaskellのようなサポートしかなかったとしたら

6582＃6929十分ではありませんか？

私は言うべきでした：...ユーザーがそのようなコア機能にアクセスするためにユニコード文字を入力することを要求したくないので、ユーザー定義の_non-unicode_中置演算子。 $は実際に追加されたものの1つであることがわかりますが、ありがとうございます。 うわー、これは実際にはJulia _today_で機能します（「高速」ではない場合でも...まだ）：

julia> ($) = map
julia> sin $ (0.5 * (abs2 $ (x-y)))

それがmapに最適かどうかはわかりませんが、 $をxorに使用するのは本当に無駄に思えます。 ビット単位のxorはそれほど頻繁には使用されません。 mapははるかに重要です。

上記の@jiahaoのポイントは非常に良いものです。 expのような個々のベクトル化された関数は、実際にはexp(-x^2)のようなベクトル化された_expressions_を取得するための一種のハックです。 @devecのような構文は、非常に価値があります。ベクトル化されていないパフォーマンスに加えて、関数をベクトル化されたものとして個別に識別する必要がないという一般性が得られます。

このために関数特性を使用する機能はすばらしいでしょうが、それでも満足のいくものではないと思います。 一般的に実際に起こっていることは、ある人が関数を書き、別の人がそれを繰り返すということです。

これは関数のプロパティではなく、関数の使用のプロパティであることに同意します。 特性の適用に関する議論は、間違った木を吠える場合のようです。

ブレーンストーミング：複数の引数のマッピングをサポートするように、マップする引数にマークを付けるのはどうですか。

a = split("the quick brown")
b = split("fox deer bear")
c = split("jumped over the lazy")
d = split("dog cat")
e = string(a, " ", b., " ", c, " ", d.) # -> 3x2 Vector{String} of the combinations   
# e[1,1]: """["the","quick", "brown"] fox ["jumped","over","the","lazy"] dog"""

.bとb.のどちらが、マッピングしたいことを示すのに適しているかはわかりません。 この場合、 map pingの形状を表すため、多次元の3x2の結果を返すのが好きです。

グレン

ここでhttps://github.com/eschnett/Vecmathlib.jlはサンプル付きのリポジトリです
expの実装。LLVMで最適化できる方法で記述されています。
この実装は、標準のexpの約2倍の速度です。
私のシステムへの実装。 それは（おそらく）まだYepppの速度に達していない、
おそらくLLVMがそれぞれのSIMDループを展開しないためです
Yepppとして積極的に。 （分解した説明書を比較しました。）

ベクトル化可能なexp関数を書くのは簡単ではありません。 使用すると次のようになります。

function kernel_vexp2{T}(ni::Int, nj::Int, x::Array{T,1}, y::Array{T,1})
    for j in 1:nj
        <strong i="16">@simd</strong> for i in 1:ni
            <strong i="17">@inbounds</strong> y[i] += vexp2(x[i])
        end
    end
end

ここで、 jループと関数の引数は次の場合にのみ存在します
ベンチマークの目的。

Julia用の@unrollマクロはありますか？

-erik

2014年11月2日午後8時26分、 TimHolynotifications @ github.comは次のように書いています。

これは関数のプロパティではなく、次のプロパティであることに同意します。
関数の使用。 特性の適用に関する議論は、
間違った木を吠える場合。

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

エリックシュネッター[email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

expのような個々のベクトル化された関数は、実際にはexp(-x^2)のようなベクトル化された_expressions_を取得するための一種のハックです。

スカラードメインから式全体を持ち上げるためのコア構文は非常に興味深いでしょう。 ベクトル化はほんの一例です（ターゲットドメインはベクトルです）。 もう1つの興味深いユースケースは、セマンティクスがまったく異なるマトリックスドメイン（＃5840）に持ち込むことです。 マトリックスドメインでは、さまざまな式でのディスパッチがどのように機能するかを調べることも役立ちます。一般的なケースでは、 sqrtmのような単純なものが必要な場合は、Schur-Parlettやその他のより特殊なアルゴリズムが必要になるためです。 （そして、巧妙な構文を使用すると、 *m関数を完全に取り除くことができます- expm 、 logm 、 sqrtm 、...）

Julia用の@unrollマクロはありますか？

Base.Cartesianを使用
@nexpr 4 d->（y [i + d] = exp（x [i + d]）

（質問がある場合は、http：//docs.julialang.org/en/latest/devdocs/cartesian/を参照してください。）

@jiahaoこれを行列関数に一般化することは興味深い挑戦のように聞こえますが、それについての私の知識はnullに近いです。 それがどのように機能するかについて何かアイデアはありますか？ それはベクトル化でどのように表現されますか？ 構文は、ベクトル/行列に要素ごとにexpを適用することと、その行列指数を計算することの違いをどのように可能にするでしょうか？

@timholy ：ありがとう！ 展開にデカルトを使用することは考えていませんでした。

残念ながら、 @nexprs （または手動で展開）によって生成されたコードは、もはやベクトル化されていません。 （これはLLVM 3.3であり、おそらくLLVM 3.5の方が良いでしょう。）

再：展開します。julia -usersに関する@toivohの投稿も参照してください。 ＃6271を試してみる価値もあるかもしれません。

@nalimilanこれについてはまだ考えていませんが、スカラー->行列のリフティングは、単一のmatrixfunc関数（たとえば）を使用して実装するのは非常に簡単です。 1つの仮想構文（完全に何かを構成する）は次のようになります。

X = randn(10,10)
c = 0.7
lift(x->exp(c*x^2)*sin(x), X)

それなら

1. Xからリフトのソースドメインとターゲットドメインを特定します。タイプMatrix{Float64}で、要素（タイプパラメーター） Float64です（したがって、暗黙的にFloat64 => Matrix{Float64}リフトを定義します） 、 それから
2. matrixfunc(x->exp(c*x^2)*sin(x), X)を呼び出して、 expm(c*X^2)*sinm(X)に相当するものを計算しますが、行列の乗算は避けます。

他のコードでは、 XはVector{Int}であり、暗黙のリフティングはIntからVector{Int}になり、 lift(x->exp(c*x^2)*sin(x), X)は$＃$ 12 $＃$になります。 map(x->exp(c*x^2)*sin(x), X)を呼び出します。

ソースドメインとターゲットドメインを明示的に指定する他のメソッド、たとえばlift(Number=>Matrix, x->exp(c*x^2)*sin(x), X)も想像できます。

@nalimilan Vectorizationは、実際にはAPIのプロパティではありません。 今日のコンパイラ技術では、関数はインラインの場合にのみベクトル化できます。 物事は主に関数の実装に依存します-それが「正しい方法」で書かれている場合、コンパイラはそれをベクトル化できます（周囲のループにインライン化した後）。

@eschnett ：他の人と同じ意味のベクトル化を使用していますか？ あなたはSIMDなどについて話しているようですが、それは私が@nalimilanの意味を理解していることではありません。

右。 ここでは、ベクトル化の2つの異なる概念があります。 1つの取引
タイトな内部ループ（プロセッサのベクトル化）のためにSIMDを取得します。 メイン
ここで議論されている問題は、どういうわけか「自動的に」の構文/意味論です
コレクションで単一（または複数）の引数関数を呼び出すことができる。

2014年11月4日火曜日午後7時4分、ジョンマイルズホワイト[email protected]
書きました：

@eschnett https://github.com/eschnett ：同じ意味を使用していますか
他の人としてのベクトル化の？ SIMDなどの話のようですね。
私が理解していることではありません@nalimilanhttps ：//github.com/nalimilan to
平均。

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

他の.演算子と対称的に、 f.(x)は関数のコレクションを値のコレクションに適用すべきではありませんか？ （たとえば、あるnd単位座標系から物理座標に変換する場合。）

構文について説明しているときに、明示的なループを使用してmap(log, x)に相当するものを表現するのは遅すぎるという概念が浮かびました。 したがって、これを十分に高速化できる場合は、 mapの呼び出し（または特別な構文の使用）またはループの記述はセマンティックレベルで同等であり、構文の曖昧性解消を導入する必要はありません。 現在、vector-log関数を呼び出すことは、配列上にループを作成するよりもはるかに高速であり、コードでこの区別を表現する方法を求めるように人々に促します。

ここには2つのレベルの問題があります：（1）構文とセマンティクス、（2）実装。

構文とセマンティクスの問題は、特定の計算を要素ごと/ブロードキャスト方式で特定の配列にマッピングする意図をユーザーがどのように表現できるかに関するものです。 現在、Juliaは2つの方法をサポートしています。ベクトル化された関数を使用する方法と、ユーザーがループを明示的に記述できるようにする方法です（マクロを使用する場合もあります）。 どちらの方法も理想的ではありません。 ベクトル化された関数を使用すると、 exp(0.5 * (x - y).^2)のような非常に簡潔な式を記述できますが、2つの問題があります。開発者側での果てしない議論とユーザー側での混乱（特定の関数がベクトル化されているかどうかを理解するためにドキュメントを検索する必要があることがよくあります）。 （2）機能の境界を越えてループを融合することを困難にします。 この時点で、おそらく数か月/年後に、コンパイラは、複数の関数を一緒に調べたり、結合データフローを識別したり、関数の境界を越えて最適化されたコードパスを生成したりするなどの複雑なタスクを実行できなくなる可能性があります。

map関数を使用すると、ここで問題（1）に対処できます。 ただし、これでも問題の解決には役立ちません（2）-特定のベクトル化された関数または一般的なmapのいずれかの関数を使用すると、ループの融合を妨げる関数境界が常に作成されます。高性能計算では重要です。 map関数を使用すると、冗長性も生じます。たとえば、上記の式はmap(exp, 0.5 * map(abs2, x - y))のように長いステートメントになります。 この問題は、より複雑な表現で悪化することを合理的に想像できます。

このスレッドで概説されているすべての提案の中で、私は個人的に、マッピングを示すために特別な表記を使用することが、今後最も有望な方法であると感じています。 まず第一に、それは表現の簡潔さを維持します。 $表記を例にとると、上記の式はexp $(0.5 * abs2$(x - y))と書くことができます。 これは元のベクトル化された式よりも少し長いですが、それほど悪くはありません。必要なのは、マッピングの各呼び出しに$を挿入することだけです。 一方、この表記は、実行されているマッピングの明確なインジケーターとしても機能します。これを使用して、コンパイラーは関数の境界を破り、融合ループを生成できます。 このコースでは、コンパイラーは関数の内部実装を調べる必要はありません。知っておく必要があるのは、関数が指定された配列の各要素にマップされることだけです。

最新のCPUのすべての機能、特にSIMDの機能を考えると、複数のループを1つに融合することは、高性能計算に向けた1つのステップにすぎません。 このステップ自体は、SIMD命令の利用をトリガーしません。 幸いなことに、 @simdマクロができました。 コンパイラーは、安全で有益であると判断した場合に、生成されたループの先頭にこのマクロを挿入できます。

要約すると、$表記（または同様の提案）は、コンパイラがループを融合してSIMDを活用し、パフォーマンスの高いコードを生成するために必要な情報を提供しながら、構文とセマンティクスの問題に大部分対処できると思います。

@lindahuaの要約は私見の良いものです。

しかし、これをさらに拡張することは興味深いと思います。 ジュリアは、多くの一般的なパターンを展開されたループと同じくらい効率的にする野心的なシステムに値します。

• ネストされた関数呼び出しを単一のループに融合するパターンも演算子に適用する必要があります。これにより、 A .* B .+ Cは2つの一時的なものを作成せず、結果として1つだけを作成します。
• 各要素の値を計算した後、その場で削減が適用されるように、要素ごとの関数と削減の組み合わせも処理する必要があります。 通常、これによりsumabs2(A)を削除し、 sum(abs$(A)$^2) （またはsum(abs.(A).^2) ）などの標準表記に置き換えることができます。
• 最後に、非標準の反復パターンは非標準の配列でサポートされる必要があります。これにより、スパース行列の場合、 A .* Bは非ゼロのエントリのみを処理し、スパース行列を返します。 これは、要素ごとの関数をSet 、 Dict 、またはRangeに適用する場合にも役立ちます。

最後の2つのポイントは、要素ごとの関数が特別なAbstractArray型を返すようにすることで機能します。たとえば、 LazyArrayは、その要素をその場で計算します（ Transposeと同様）。 https://github.com/JuliaLang/julia/issues/4774#issuecomment-59422003から入力します）。 ただし、 1からlength(A)までの線形インデックスを使用して要素に単純にアクセスする代わりに、イテレータプロトコルを使用できます。 特定のタイプのイテレータは、タイプのストレージレイアウトに応じて、行単位または列単位の反復が最も効率的かどうかを自動的に選択します。 また、スパース行列の場合、ゼロエントリをスキップできます（元のエントリと結果は共通の構造を持つ必要があります。https：//github.com/JuliaLang/julia/issues/7010、https：// githubを参照してください。 com / JuliaLang / julia / issues / 7157）。

リダクションが適用されていない場合、元のオブジェクトと同じタイプと形状のオブジェクトは、 LazyArray （ collectに相当しますが、元の配列のタイプを尊重します）を反復処理するだけで埋められます。 ）。 そのために必要なのは、イテレータがオブジェクトを返すことだけです。このオブジェクトを使用して、 LazyArrayでgetindexを呼び出し、結果でsetindex!を呼び出すことができます（線形またはデカルト座標など）。座標）。

リダクションが適用されると、引数に関連する反復法を使用して、 LazyArrayの必要な次元を反復処理し、配列に結果を入力します（ reduceに相当しますが、配列タイプに適応するカスタムイテレータ）。 1つの関数（最後の段落で使用されている関数）は、最も効率的な方法ですべての要素を処理するイテレーターを返します。 他の人は特定の次元でそうすることを許可するでしょう。

このシステム全体は、インプレース操作も非常に簡単にサポートします。

構文に対処することについて少し考えていて、要素ごとの操作を配列に適用するための.=について考えました。
したがって、 @ nalimilanの例sum(abs.(A).^2))は、残念ながら2つのステップで記述する必要があります。

A = [1,2,3,4]
a .= abs(A)^2
result = sum(a)

これには読みやすいという利点があり、配列固有のメソッドを記述する代わりに、要素ごとの関数を単一（または複数）の入力に対して記述し、その場合に最適化するだけでよいことを意味します。

もちろん、パフォーマンスと親しみやすさ以外の何物も、述べられているように、誰もが今すぐmap((x) -> abs(x)^2, A)を書くことを妨げるものではありません。

または、 .()でマップする式を囲むこともできます。
これを行うのがどれほど難しいかはわかりませんが、 .sin(x)と.(x + sin(x))は、括弧内または.に続く関数のいずれかで式をマップします。
これにより、 @ nalimilanの例のように、 sum(.(abs(A)^2))を1行で書き込むことができるようになります。

これらの提案は両方とも.プレフィックスを使用しており、内部でブロードキャストを使用しているときに、配列の要素ごとの操作について考えさせられました。 これは、 $または別の記号と簡単に交換できます。
これは、マップされるすべての関数の周りにマップ演算子を配置し、代わりに式全体をグループ化して、代わりにマップされるように指定する代わりの方法です。

私は最後のコメントで公開したLazyArrayのアイデアを試しました： https ：//gist.github.com/nalimilan/e737bc8b3b10288abdad

この概念実証には構文上の糖衣はありませんが、 (a ./ 2).^2は、要点にLazyArray(LazyArray(a, /, (2,)), ^, (2,))と書かれているものに変換されます。 システムは非常にうまく機能しますが、パフォーマンスに関してループとリモートで競合するには、さらに最適化する必要があります。 （予想される）問題は、追加の引数が許可されていないバージョンでも、12行目の関数呼び出しが最適化されていない（ほとんどすべての割り当てがそこで行われる）ことであるようです。 呼び出す関数のLazyArrayをパラメーター化する必要があると思いますが、引数の処理は言うまでもなく、それをどのように実行できるかわかりません。 何か案は？

LazyArrayのパフォーマンスを改善する方法について何か提案はありますか？

@nalimilan 1年前に同様のアプローチを試し、NumericFunsのファンクター型を使用して遅延式の型をパラメーター化しました。 さまざまなトリックを試しましたが、パフォーマンスのギャップを埋めることができませんでした。

コンパイラの最適化は、過去1年間で徐々に改善されてきました。 しかし、それでも不要なオーバーヘッドを最適化することはできないと感じています。 この種のことは、コンパイラーが積極的なインライン関数を必要とします。 @inlineを使用してみて、状況が改善されるかどうかを確認してください。

@lindahua @inlineはタイミングに違いはありません。これは、 getindex(::LazyArray, ...)が特定のLazyArray署名に特化しているため、論理的です。これは、どの関数を指定する必要があるかを指定しません。呼ばれる。 LazyArray{T1, N, T2, F}のようなものが必要です。Fは呼び出される関数なので、 getindexをコンパイルするときに呼び出しがわかります。 それを行う方法はありますか？

インライン化はさらにもう1つの大きな改善ですが、現時点では、インライン化されていない呼び出しよりもタイミングがはるかに悪くなっています。

NumericFunsの使用を検討することができ、 Fはファンクタータイプにすることができます。

Dahua

分散のリターンタイプがわかっている関数が必要でした
結果の前に結果への参照を作成するコンピューティング（および
したがって、そのタイプ）は既知です。 私は自分で非常によく似たものを実装しました、そして
おそらく「ファンクター」と呼ばれるものを使用するように切り替える必要があります。 （私は好きではありません
通常は別のものであるため、「ファンクター」という名前を付けます<
http://en.wikipedia.org/wiki/Functor>ですが、C ++が水を混乱させたと思います
ここ。）

ファンクターの部分をから分割するのは理にかなっていると思います
数学関数。

-erik

2014年11月20日木曜日午前10時35分、Dahua [email protected]
書きました：

NumericFunsの使用を検討することができ、Fはファンクタータイプにすることができます。

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

エリックシュネッター[email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@lindahuaファンクターを使用してみましたが、実際、パフォーマンスははるかに合理的です。
https://gist.github.com/nalimilan/d345e1c080984ed4c89a

With functions:
# elapsed time: 3.235718017 seconds (1192272000 bytes allocated, 32.20% gc time)

With functors:
# elapsed time: 0.220926698 seconds (80406656 bytes allocated, 26.89% gc time)

Loop:
# elapsed time: 0.07613788 seconds (80187556 bytes allocated, 45.31% gc time) 

生成されたコードはまだ最適ではないように思われるため、改善のためにこれ以上何ができるかわかりません。 何が悪いのかを知るには、もっと専門家の目が必要です。

実際、上記のテストではPowを使用しました。これは、明示的なループを作成するか、 LazyArrayを使用するかによって、明らかに速度に大きな違いがあります。 これは、後者の場合にのみ実行される命令の融合に関係していると思います。 同じ現象は、例えば加算で見られます。 しかし、他の関数では、100x100または1000x1000マトリックスのいずれかを使用した場合、違いははるかに小さくなります。おそらく、それらは外部であり、したがってインライン化はあまり得られないためです。

# With sqrt()
julia> test_lazy!(newa, a);
julia> <strong i="8">@time</strong> for i in 1:1000 test_lazy!(newa, a) end
elapsed time: 0.151761874 seconds (232000 bytes allocated)

julia> test_loop_dense!(newa, a);
julia> <strong i="9">@time</strong> for i in 1:1000 test_loop_dense!(newa, a) end
elapsed time: 0.121304952 seconds (0 bytes allocated)

# With exp()
julia> test_lazy!(newa, a);
julia> <strong i="10">@time</strong> for i in 1:1000 test_lazy!(newa, a) end
elapsed time: 0.289050295 seconds (232000 bytes allocated)

julia> test_loop_dense!(newa, a);
julia> <strong i="11">@time</strong> for i in 1:1000 test_loop_dense!(newa, a) end
elapsed time: 0.191016958 seconds (0 bytes allocated)

そこで、 LazyArrayで最適化が行われない理由を知りたいと思います。 生成されたアセンブリは、単純な操作では非常に長くなります。 たとえば、 x/2 + 3の場合：

julia> a1 = LazyArray(a, Divide(), (2.0,));

julia> a2 = LazyArray(a1,  Add(), (3.0,));

julia> <strong i="17">@code_native</strong> a2[1]
    .text
Filename: none
Source line: 1
    push    RBP
    mov RBP, RSP
Source line: 1
    mov RAX, QWORD PTR [RDI + 8]
    mov RCX, QWORD PTR [RAX + 8]
    lea RDX, QWORD PTR [RSI - 1]
    cmp RDX, QWORD PTR [RCX + 16]
    jae L64
    mov RCX, QWORD PTR [RCX + 8]
    movsd   XMM0, QWORD PTR [RCX + 8*RSI - 8]
    mov RAX, QWORD PTR [RAX + 24]
    mov RAX, QWORD PTR [RAX + 16]
    divsd   XMM0, QWORD PTR [RAX + 8]
    mov RAX, QWORD PTR [RDI + 24]
    mov RAX, QWORD PTR [RAX + 16]
    addsd   XMM0, QWORD PTR [RAX + 8]
    pop RBP
    ret
L64:    movabs  RAX, jl_bounds_exception
    mov RDI, QWORD PTR [RAX]
    movabs  RAX, jl_throw_with_superfluous_argument
    mov ESI, 1
    call    RAX

同等のものとは対照的に：

julia> fun(x) = x/2.0 + 3.0
fun (generic function with 1 method)

julia> <strong i="21">@code_native</strong> fun(a1[1])
    .text
Filename: none
Source line: 1
    push    RBP
    mov RBP, RSP
    movabs  RAX, 139856006157040
Source line: 1
    mulsd   XMM0, QWORD PTR [RAX]
    movabs  RAX, 139856006157048
    addsd   XMM0, QWORD PTR [RAX]
    pop RBP
    ret

jae L64までの部分は、配列境界チェックです。 @inboundsを使用すると役立つ場合があります（適切な場合）。

2つの連続する行がmov RAX, ...で始まる以下の部分は、二重間接参照です。つまり、ポインター（または配列の配列、または配列へのポインターなど）へのポインターにアクセスします。 これは、LazyArrayの内部表現に関係している可能性があります。おそらく、不変を使用する（またはJuliaによって不変を別の方法で表現する）ことがここで役立つ場合があります。

いずれにせよ、コードはまだかなり高速です。 高速化するには、呼び出し元にインライン化して、さらに最適化の機会を公開する必要があります。 この式をループなどから呼び出すとどうなりますか？

また、これをREPLからではなく、関数内から逆アセンブルするとどうなりますか？

また、最初のバージョンが実際に実行されることに気付かずにはいられません
2番目がx / 2を乗算に変換している間に除算。

コメントありがとうございます。

@eschnett LazyArrayはすでに不変であり、ループで@inboundsを使用しています。 https://gist.github.com/nalimilan/d345e1c080984ed4c89aで要点を実行した後、これでループ内で何が得られるかを確認できます。

function test_lazy!(newa, a)
    a1 = LazyArray(a, Divide(), (2.0,))
    a2 = LazyArray(a1, Add(), (3.0,))
    collect!(newa, a2)
    newa
end
<strong i="11">@code_native</strong> test_lazy!(newa, a); 

だから多分私が必要なのはインライン化を強制できることだけですか？ 私の試みでは、 @inlineをgetindexに追加しても、タイミングは変わりません。

@toivoh後者の場合、除算が単純化されていないことを説明できるのは何ですか？

私は2つの引数のバージョン（ LazyArray2と呼ばれる）で実験を続けました。 x .+ yのような単純な操作であることがわかりました。実際には、現在の.+ LazyArray2を使用する方が高速であり、明示的なループにもかなり近いです（これらは1000回の呼び出し用です）。 、https：//gist.github.com/nalimilan/d345e1c080984ed4c89aを参照）：

# With LazyArray2, filling existing array
elapsed time: 0.028212517 seconds (56000 bytes allocated)

# With explicit loop, filling existing array
elapsed time: 0.013500379 seconds (0 bytes allocated)

# With LazyArray2, allocating a new array before filling it
elapsed time: 0.098324278 seconds (80104000 bytes allocated, 74.16% gc time)

# Using .+ (thus allocating a new array)
elapsed time: 0.078337337 seconds (80712000 bytes allocated, 52.46% gc time)

したがって、この戦略は、 .+ 、 .*などの演算子を含むすべての要素ごとの演算を置き換えることが実行可能であるように見えます。

また、行列の次元に沿った差の2乗の合計、つまりsum((x .- y).^2, 1)を計算するなどの一般的な操作を実現することも非常に競争力があるように見えます（要点をもう一度参照してください）。

# With LazyArray2 and LazyArray (no array allocated except the result)
elapsed time: 0.022895754 seconds (1272000 bytes allocated)

# With explicit loop (no array allocated except the result)
elapsed time: 0.020376307 seconds (896000 bytes allocated)

# With element-wise operators (temporary copies allocated)
elapsed time: 0.331359085 seconds (160872000 bytes allocated, 50.20% gc time)

@nalimilan
LazyArraysを使用したアプローチは、蒸気融合がHaskellで機能する方法と似ているようです[1、2]。 たぶん、そのエリアからのアイデアを適用することができますか？

[1] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7401
[2] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.421.8551

@vchuravyありがとう。 これは確かに似ていますが、ジュリアが命令モデルを使用しているため、より複雑です。 それどころか、Haskellでは、コンパイラはさまざまなケースを処理する必要があり、SIMDの問題（Juliaの後の時点でLLVMによって処理される）も処理する必要があります。 しかし、正直なところ、これらの論文のすべてを解析することはできません。

@nalimilan私はその気持ちを知っています。 2番目の論文は、一般化されたストリームフュージョンについて説明しているため、特に興味深いと思いました。これにより、ベクトルに対する優れた計算モデルが可能になるようです。

怠惰と組み合わせたmapやreduceのような構成は、十分に高速（または明示的なループよりもさらに高速）になる可能性があるということから、私たちが取るべき主なポイントだと思います。

私が知る限り、中括弧は呼び出し構文で引き続き使用できます。 これがfunc{x}になった場合はどうなりますか？ 多分少し無駄すぎますか？

（SIMDの意味での）高速ベクトル化のトピックに関して、Eigenが行う方法をエミュレートできる方法はありますか？

これは、現在のすべての要素ごとの操作を、上記のLazyArrayおよびLazyArray2と呼んだものの一般化に置き換える提案です。 もちろん、これは、NumericFuns.jlのファンクターに依存することなく、すべての関数でこれを高速化できるという前提に基づいています。

1）新しい構文f.(x)またはf$(x) 、またはx f() LazyArrayを作成するものを追加します。

2） broadcastが現在どのように機能するかに従って、この構文を一般化します。たとえば、 f.(x, y, ...)またはf$(x, y, ...)はLazyArray $を作成しますが、シングルトン次元をxに拡張します。 y 、...それらに共通のサイズを与えるため。 もちろん、これはインデックスの計算によってオンザフライで実行されるため、拡張された配列は実際には割り当てられません。

3） .+ 、 .- 、 .* 、 ./ 、 .^などを作成します。$の代わりにbroadcast LazyArrayを使用します。 broadcast 。

4）新しい代入演算子.=または$=を導入します。これにより、 LazyArrayが実際の配列に変換されます（ collectを呼び出します）。プロモーションルールを介した入力、および入力の要素タイプと呼び出された関数に応じた要素タイプ）。

5） broadcastをLazyArrayの呼び出しと、結果の即時collectイオンを実際の配列に置き換えることもできます。

ポイント4は重要です。要素ごとの操作は実際の配列を返すことはなく、常にLazyArrayであるため、複数の操作を組み合わせる場合、コピーは作成されず、ループを融合して効率を上げることができます。 これにより、一時的なものを割り当てることなく、結果sumのような削減を呼び出すことができます。 したがって、この種の式は、密な配列と疎な行列の両方で、慣用的で効率的です。

y .= sqrt.(x .+ 2)
y .=  √π exp.(-x .^ 2) .* sin.(k .* x) .+ im * log.(x .- 1)
sum((x .- y).^2, 1)

この種の軽量オブジェクトを返すことは、配列ビューとTranspose / CTransposeの新しい図に完全に適合すると思います。 これは、Juliaでは、高密度で読みやすい構文を使用して複雑な操作を非常に効率的に実行できることを意味しますが、「疑似配列」をから独立させる必要がある場合は、明示的にcopyを呼び出す必要があります。それが基づいている実際の配列。

これは本当に重要な機能のように聞こえます。 要素ごとの演算子の現在の動作は、構文が素晴らしく短いため、新しいユーザーにとっては罠ですが、パフォーマンスは通常ひどく悪く、Matlabよりも明らかに劣っています。 先週、julia-usersのいくつかのスレッドでパフォーマンスの問題が発生しましたが、このような設計では解消されます。
https://groups.google.com/d/msg/julia-users/t0KvvESb9fA/6_ZAp2ujLpMJ
https://groups.google.com/d/msg/julia-users/DL8ZsK6vLjw/w19Zf1lVmHMJ
https://groups.google.com/d/msg/julia-users/YGmDUZGOGgo/LmsorgEfXHgJ

この問題の目的のために、私は構文を怠惰から分離します。 しかし、あなたの提案は興味深いものです。

_ドットが非常に多い_という点が来ているようです。 特に真ん中の例は、次のように書く方がよいでしょう。

x .|> x->exp(-x ^ 2) * sin(k * x) + im * log(x - 1)

これには、基本的な機能と効率的なmap （ .|> ）のみが必要です。

これは興味深い比較です：

y .=  √π exp.(-x .^ 2) .* sin.(k .* x) .+ im * log.(x .- 1)
y =  [√π exp(-x[i]^ 2) .* sin(k * x[i]) .+ im * log(x[i] - 1) for i = 1:length(x)]

for ...の部分を割り引くと、理解度は1文字長くなります。 私は、これらすべてのドットよりも、ほとんどの場合、省略された理解構文を使用したいと思います。

1次元の理解は形を維持しませんが、今ではfor i in eachindex(x)も変更される可能性があります。

内包表記の問題の1つは、データ配列をサポートしていないことです。

LazyArrayのアイデアに非常によく似た.Netで起こったたくさんのことを見る価値があると思います。 基本的に、これはLINQスタイルのアプローチに非常に近いように見えます。ここでは、現在の要素ごとの構文に似ていますが、実際にはその構文によって式ツリーが構築され、その式ツリーは後で効率的な方法で評価されます。 。 それはどういうわけか近いですか？

.Netでは、これらの式ツリーを複数のCPUで並列に実行する（.AsParallel（）を追加する）か、DryadLINQを使用して大規模なクラスターで実行するか、 http：/で実行することができます。

私の感覚では、Blazeもその方向に進んでいます。つまり、計算を記述するオブジェクトを簡単に構築する方法です。そうすれば、さまざまな実行エンジンを使用できます。

これが非常に明確かどうかはわかりませんが、この問題全体は、コードのような低レベルの効率的なSIMDを生成する方法と、これをGPUコンピューティング、クラスタリング、並列に使用する方法の両方のコンテキストで検討する必要があるように思われます計算など。

はい、その通りです。長い例ではドットが多すぎます。 ただし、2つの短い方が一般的であり、その場合は短い構文を使用することが重要です。 構文を怠惰から分離したいのですが、あなたのコメントがそれが非常に難しいように見えることを示しているので、私たちは常に2つを混ぜ合わせます！

y = [sqrt(x + 2) over x]のような理解構文を適応させることを想像することができます。 しかし、 @ johnmyleswhiteが指摘したように、 DataArraysだけでなく、スパース行列や新しい配列型もサポートする必要があります。 したがって、これも構文と機能を混在させる場合です。

より基本的には、私の提案が代替案に対して提供する2つの機能は次のとおりです。
1） y[:] = sqrt.(x .+ 2)を使用した割り当てなしのインプレース割り当てのサポート。
2） sum((x .- y).^2, 1)のような割り当てのない削減のサポート。

それは他の解決策（構文の問題を無視して）で提供できますか？

@davidanthoffありがとうございます。今見てください（並列コンピューティングをサポートするためにLazyArrayを作成できると思います）。

おそらく、これはジェネレーターと組み合わせることができます—それらは一種の怠惰な配列でもあります。 私は[f(x) over x]の理解構文がいくらか好きですが、初心者にとっては概念的に難しいかもしれません（同じ名前が要素と配列自体の両方に効果的に使用されているため）。 角かっこなしの内包表記がジェネレーターを作成する場合（私がずっと前に遊んだように）、角かっこなしのこれらの新しいover-x-style-内包表記を使用して、LazyArrayをすぐに収集するのではなく返すのが自然です。

@mbaumanはい、ジェネレーターとレイジー配列は多くのプロパティを共有しています。 ブラケットを使用してジェネレーター/レイジー配列を収集し、レイジーオブジェクトをクールに保つためにブラケットを追加しないというアイデア。 したがって、上記の私の例に関しては、1） y[:] = sqrt(x + 2) over xとsum((x - y)^2 over (x, y), 1)の両方を書くことができます（初心者でも当然だと思いますが、 overの問題はそのままにしておきましょうバイクシェディングセッションと最初に基本に集中します）。

私はf(x) over xのアイデアが好きです。 f(x) for xを使用して、新しいキーワードを回避することもできます。 実際[f(x) for x=x]すでに機能しています。 次に、 mapと同等の内包表記を作成して、非配列で機能できるようにする必要があります。 Arrayがデフォルトになります。

私もoverのアイデアが好きになったことを認めなければなりません。 マップとしてのover forの違いの1つは、複数のイテレータの場合に何が起こるかです。 [f(x, y) for x=x, y=y]は行列になります。 マップの場合、通常はベクトルが必要です。つまり、 [f(x, y) over x, y]は[f(x, y) for (x,y) = zip(x, y)]]と同等です。 このため、追加のキーワードoverを導入する価値があると思います。この問題が発生したため、複数のベクトルに対するmapの使用は非常に一般的であり、簡潔にする必要があるためです。

ねえ、私は構文についてジェフを説得しました！ ;-)

これは＃4470の横にあるので、今のところ0.4プロジェクトに追加します。

議論の要点を理解している場合、主な問題は、次のようなマッピングのような構文を取得したいということです。

• ネイティブ配列だけでなく、DataArrayなどのさまざまなデータ型で機能します。
• 手動で記述されたループと同じくらい高速です。

インライン化を使用してそれを行うことは可能かもしれませんが、インライン化が機能することを確認するために本当に注意してください。

別のアプローチについてはどうですか：推測されたデータ型に応じてマクロを使用します。 データ構造がDataArrayであると推測できる場合は、DataArraysライブラリによって提供されるmap-macroを使用します。 SomeKindOfStreamの場合は、提供されているストリームライブラリを使用します。 タイプを推測できない場合は、動的にディスパッチされた一般的な実装を使用します。

これにより、データ構造の作成者はそのようなマクロを作成する必要がありますが、作成者が本当に効率的に実行することを望んでいる場合にのみ必要になります。

私が書いていることが不明確な場合、 [EXPR for i in collection if COND]のようなものが$ eval(collection_mapfilter_macro(:(i), :(EXPR), :(COND)))に変換される可能性があることを意味します。ここで、 collection_mapfilter_macroは推測されたコレクションタイプに基づいて選択されます。

いいえ、そのようなことはしたくありません。 DataArrayがmap （または同等のもの）を定義する場合、何を推測できるかに関係なく、その定義は常にDataArrayに対して呼び出される必要があります。

この問題は実際には実装に関するものではなく、構文に関するものです。 現在、 xが配列の場合、多くの人がsin(x)暗黙的にマッピングすることに慣れていますが、そのアプローチには多くの問題があります。 問題は、どの代替構文が受け入れられるかということです。

1） y[:] = sqrt.(x .+ 2)を使用した割り当てのないインプレース割り当てのサポート
2） sum((x .- y).^2, 1)のような割り当てのない削減のサポート

y =√πexp（-x ^ 2）* sin（k * x）+ im * log（x-1）

他の人からのこれらの3つの例を見ると、 for構文を使用すると、次のようになります。
1） y[:] = [ sqrt(x + 2) for x ])
2） sum([ (x-y)^2 for x,y ], 1)
と
y = [ √π exp(-x^2) * sin(k*x) + im * log(x-1) for x,k ]

私はこれがとても好きです！ それが一時配列を作成するという事実は非常に明白であり、それでも読みやすく簡潔です。

ちょっとした質問ですが、 x[:] = [ ... for x ]には、一時的な配列を割り当てずに配列を変更する魔法がありますか？
これが多くのメリットをもたらすかどうかはわかりませんが、大規模なアレイに役立つと想像できます。
それは別の場所で議論されるべき完全に異なる魚のやかんかもしれないと私は信じることができます。

@ Mike43110 x[:] = [ ... for x ]はx[:] = (... for x)と書くことができ、RHSはジェネレーターを作成します。ジェネレーターは、コピーを割り当てずに、要素ごとに収集されてxを埋めます。 それが、上記のLazyArray実験の背後にある考え方でした。

[f <- y]構文は、出力タイプを認識し、 f(y[1])から他の要素を補間する必要がないマップのInt[f <- y]構文と組み合わせると便利です。

特に、これはmapslicesにも直感的なインターフェースを提供するため、 [f <- rows(A)] rows(A) （またはcolumns(A)またはslices(A, dims) ）が$を返す$＃$ 1 $＃ Sliceオブジェクトなので、ディスパッチを使用できます。

map(f, slice::Slice) = mapslices(f, slice.A, slice.dims)

インデックスを追加すると、これは少し難しくなります。 例えば

f(x[:,j]) .* g(x[i,:])

その簡潔さに合わせるのは難しいです。 理解スタイルからの爆発はかなり悪いです：

[f(x[m,j])*g(x[i,n]) for m=1:size(x,1), n=1:size(x,2)]

さらに悪いことに、これはネストされた反復の場合であり、単一のover実行できないことを知るために賢さが必要でした。 fとgが少し高価な場合でも、これはもっと速いかもしれません：

[f(x[m,j]) for m=1:size(x,1)] .* [g(x[i,n]) for _=1, n=1:size(x,2)]

しかし、さらに長くなります。

この種の例は、 f.(x[:,j]) .* g.(x[i,:])を与える可能性があるため、「ドット」を主張しているようです。

@JeffBezansonあなたのコメントの意図がわかりません。 .*構文を取り除くことを提案した人はいますか？

番号; ここではfとgに焦点を当てています。 これは、行の最後にover xを追加できない例です。

はい、わかりました。コメントの終わりを見逃していました。 確かに、その場合はドットバージョンの方が優れています。

配列ビューを使用しますが、適度に効率的（AFAICT）であり、それほど醜い代替手段はありません。
[ f(y) * g(z) for y in x[:,j], z in x[i,:] ]

上記の例は、キーワードをネストすることで解決できますか？

f(x)*g(y) over x,y

として解釈されます

[f(x)*g(y) for (x,y) = zip(x,y)]

一方

f(x)*g(y) over x over y

になります

[f(x)*g(y) for x=x, y=y]

次に、上記の具体的な例は次のようになります

f(x[:,n])*g(x[m,:]) over x[:,n] over x[m,:]

編集：振り返ってみると、それは私が思っていたほど簡潔ではありません。

@JeffBezansonはどうですか

f(x[:i,n]) * g(x[m,:i]) over i

f.(x[:,n] .* g.(x[m,:])に相当します。 新しい構文x[:i,n]は、 iがコンテナx[:,n]のインデックスに対するイテレータとしてローカルに導入されていることを意味します。 それを実装できるかどうかはわかりません。 しかし、それは（一応）醜くも面倒でもないようであり、構文自体がイテレータの境界、つまり1：length（x [：、n]）を与えます。 キーワードに関する限り、「over」は範囲全体が使用されることを示すことができますが、「for」は、ユーザーが1：length（x [：、n]）のサブ範囲を指定する場合に使用できます。

f(x[:i,n]) * g(x[m,:i]) for i in 1:length(x[:,n])-1 。

@davidagold 、 :iすでにシンボルiを意味します。

はい、良い点です。 まあ、ドットが公正なゲームである限り、どうですか

f(x[.i,n]) * g(x[m,.i]) over i

ここで、ドットは、 iが1：length（x [：、n）を超えるイテレータとしてローカルに導入されていることを示します。 本質的に、これはドット表記を関数の変更から配列の変更、またはむしろそれらのインデックスに切り替えると思います。 これにより、ジェフが指摘した「ドットクリープ」から1つを節約できます。

[ f(g(e^(x[m,.i]))) * p(e^(f(y[.i,n]))) over i ]

とは対照的に

f.(g.(e.^(x[m,:]))) .* p.(e.^(f.(y[:,n])))

後者は少し短いと思いますが。 [編集：また、あいまいさがないときにover iを省略できる場合は、実際にはわずかに短い構文になります。

[ f(g(e^(x[m,.i]))) * p(e^(f(y[.i,n]))) ] ]

理解構文の潜在的な利点の1つは、要素ごとの操作のパターンの範囲を広げることができることです。 たとえば、パーサーがx[m, .i]のiを使用したインデックス付けが暗黙的にモジュロ長（x [m 、：]）であることを理解した場合、次のように記述できます。

[ f(x[.i]) * g(y[.j]) over i, j=-i ]

xの要素とyの要素を逆の順序で乗算します。つまり、 xの最初の要素とyの最後の要素などを乗算します。 。書くことができます

[ f(x[.i]) * g(y[.j]) over i, j=i+1 ]

xのi番目の要素にyのi+1番目の要素を掛ける（ xの最後の要素が掛けられる）このコンテキストではモジュロ長（x）として理解されるインデックス付けのため、 yの最初の要素によって。 そして、 p::Permutationが（1、...、length（x））を並べ替える場合、次のように書くことができます。

[ f(x[.i]) * g(y[.j]) over i, j=p(i) ]

xのi番目の要素にyのp(i)番目の要素を掛けます。

とにかく、それは完全に投機的な問題についての部外者からの謙虚な意見です。 = p誰もがそれを検討するのにかかる時間に感謝します。

rスタイルのリサイクルを使用するvectorizeの強化バージョンは、非常に便利です。 つまり、最大の引数のサイズと一致しない引数は、リサイクルによって拡張されます。 そうすれば、ユーザーは引数の数などに関係なく、必要なものを簡単にベクトル化できます。

unvectorized_sum(a, b, c, d) = a + b + c + d
vectorized_sum = @super_vectorize(unvectorized_sum)

a = [1, 2, 3, 4]
b = [1, 2, 3]
c = [1, 2]
d = 1

A = [1, 2, 3, 4]
B = [1, 2, 3, 1]
C = [1, 2, 1, 2]
D = [1, 1, 1, 1]

vectorized_sum(a, b, c, d) = vectorized_sum(A, B, C, D) = [4, 7, 8, 8]

リサイクルは安全性と利便性のトレードオフだと思う傾向があります。 リサイクルを使用すると、エラーを発生させずに実行されるバグのあるコードを非常に簡単に記述できます。

Rのその振る舞いについて初めて読んだとき、なぜ誰かがそれが良い考えだと思うのかとすぐに思いました。 これは、サイズの不一致の配列に対して暗黙的に行うことは、本当に奇妙で驚くべきことです。 小さい配列を拡張する方法がいくつかある場合もありますが、同様に、ゼロパディングまたは終了要素の繰り返し、外挿、エラー、またはその他のアプリケーションに依存する任意の数が必要な場合もあります。選択肢。

@super_vectorizeを使用するかどうかは、ユーザーの手に委ねられます。 さまざまな場合に警告を出すことも可能です。 たとえば、Rでは、

c(1, 2, 3) + c(1, 2)
[1] 2 4 4
Warning message:
In c(1, 2, 3) + c(1, 2) :
  longer object length is not a multiple of shorter object length

ユーザーが使用するかどうかを選択できるオプションのものを作成することに異論はありませんが、パッケージで実行できる場合は、基本言語で実装する必要はありません。

@vectorize_1argと@vectorize_2argはどちらもすでにBaseに含まれており、ユーザーに提供するオプションは多少制限されているようです。

ただし、この問題は、Baseから@vectorize_1argと@vectorize_2argを削除するためのシステムの設計に焦点を当てています。 私たちの目標は、言語からベクトル化された関数を削除し、それらをより優れた抽象化に置き換えることです。

たとえば、リサイクルは次のように書くことができます

[ A[i] + B[mod1(i,length(B))] for i in eachindex(A) ]

これは私にとって、それを書くための理想的な方法にかなり近いものです。 誰もあなたのためにそれを組み込む必要はありません。 主な質問は、（1）これをより簡潔にすることができるか、（2）他のコンテナタイプに拡張する方法です。

@davidagoldの提案を見て、変数がコロンの前の名前になるようなものにはvar:を使用できないのではないかと思いました。 この構文はA[var:end]を意味するので、利用できるようです。

f(x[:,j]) .* g(x[i,:])はf(x[a:,j]) * g(x[i,b:]) for a, bになりますが、それほど悪くはありません。

ただし、複数のコロンは少し奇妙です。

f(x[:,:,j]) .* g(x[i,:,:]) -> f(x[a:,a:,j]) * g(x[i,b:,b:]) for a, bはこれについての私の最初の考えでした。

さて、これがリサイクルプログラムの簡単な説明です。 n次元配列を処理できる必要があります。 タプルをベクトルに類似して組み込むことはおそらく可能でしょう。

using DataFrames

a = [1, 2, 3]
b = 1
c = [1 2]
d = <strong i="6">@data</strong> [NA, 2, 3]

# coerce an array to a certain size using recycling
coerce_to_size = function(argument, dimension_extents...)

  # number of repmats needed, initialized to 1
  dimension_ratios = [dimension_extents...]

  for dimension in 1:ndims(argument)

    dimension_ratios[dimension] = 
      ceil(dimension_extents[dimension] / size(argument, dimension))
  end

  # repmat array to at least desired size
  if typeof(argument) <: AbstractArray
    rep_to_size = repmat(argument, dimension_ratios...)
  else
    rep_to_size = 
      fill(argument, dimension_ratios...)
  end

  # cut down array to exactly desired size
  dimension_ranges = [1:i for i in dimension_extents]
  dimension_ranges = tuple(dimension_ranges...)

  rep_to_size = getindex(rep_to_size, dimension_ranges...)  

end

recycle = function(argument_list...)

  # largest dimension in arguments
  max_dimension = maximum([ndims(i) for i in argument_list])
  # initialize dimension extents to 1
  dimension_extents = [1 for i in 1:max_dimension]

  # loop through argument and dimension
  for argument_index in 1:length(argument_list)
    for dimension in 1:ndims(argument_list[argument_index])
      # find the largest size for each dimension
      dimension_extents[dimension] = maximum([
        size(argument_list[argument_index], dimension),
        dimension_extents[dimension]
      ])
    end
  end

  expand_arguments = 
    [coerce_to_size(argument, dimension_extents...) 
     for argument in argument_list]
end

recycle(a, b, c, d)

mapply = function(FUN, argument_list...)
  argument_list = recycle(argument_list...)
  FUN(argument_list...)
end

mapply(+, a, b, c, d)

明らかに、これは最もエレガントで高速なコードではありません（私は最近のR移民です）。 ここから@vectorizeマクロに移動する方法がわかりません。

編集：結合された冗長ループ
編集2：サイズに強制を分離しました。 現在、0〜2次元でのみ機能します。
編集3：これを行うもう少し洗練された方法の1つは、modインデックスを使用して特別なタイプの配列を定義することです。 あれは、

special_array = [1 2; 3 5]
special_array.dims = (10, 10, 10, 10)
special_array[4, 1, 9, 7] = 3

編集4：これを書くのが難しかったので私が疑問に思っていることが存在します：hcatとvcatのn次元の一般化？ n次元配列（特定の配列のサイズに一致する）を、特定の各位置のインデックスのリストまたはタプルで埋める方法はありますか？ repmatのn次元の一般化？

[pao：構文の強調表示]

Juliaでfoo = function(x,y,z) ... end構文を使用して関数を定義することは実際には必要ありませんが、機能します。 これにより、無名関数への名前の非定数バインディングが作成されます。 ジュリアでは、総称関数を使用するのが一般的であり、関数へのバインドは自動的に一定です。 そうしないと、ひどいパフォーマンスが得られます。

ここでrepmatが必要な理由がわかりません。 各位置のインデックスで満たされた配列も警告サインです。非常に少ない情報を表すために大量のメモリを使用する必要はありません。 このような手法は、すべてを「ベクトル化」する必要がある言語でのみ実際に役立つと思います。 https://github.com/JuliaLang/julia/issues/8450#issuecomment -111898906のように、いくつかのインデックスが変換されるループを実行するのが正しいアプローチのように思えます。

はい、それは理にかなっています。 これが始まりですが、最後にループを実行してから@vectorizeマクロを作成する方法を理解するのに苦労しています。

function non_zero_mod(big::Number, little::Number)
  result = big % little
  result == 0 ? little : result
end

function mod_select(array, index...)
  # just return singletons
  if !(typeof(array) <: AbstractArray) return array end
  # find a new index with moded values
  transformed_index = 
      [non_zero_mod( index[i], size(array, i) )
       for i in 1:ndims(array)]
  # return value at moded index
  array[transformed_index...]
end

function mod_value_list(argument_list, index...)
  [mod_select(argument, index...) for argument in argument_list]
end

mapply = function(FUN, argument_list...)

  # largest dimension in arguments
  max_dimension = maximum([ndims(i) for i in argument_list])
  # initialize dimension extents to 1
  dimension_extents = [1 for i in 1:max_dimension]

  # loop through argument and dimension
  for argument_index in 1:length(argument_list)
    for dimension in 1:ndims(argument_list[argument_index])
      # find the largest size for each dimension
      dimension_extents[dimension] = maximum([
        size(argument_list[argument_index], dimension),
        dimension_extents[dimension]
      ])
    end
  end

  # more needed here
  # apply function over arguments using mod_value_list on arguments at each position
end

講演の中で、 @ JeffBezansonは構文sin(x) over xについて言及しましたが、次のようなものはどうでしょうか。
sin(over x) ？ （または、キーワードとしてoverを使用する代わりに、いくつかの文字を使用します）

これが解決されたら、＃11872も解決できます

パーティーに遅れないことを願っていますが、 @ davidagoldの構文提案に+1を提供したいと思います。 概念的に明確で簡潔で、書くのは本当に自然なことです。 .が最適な識別文字であるかどうか、または実際の実装がどれほど実行可能であるかはわかりませんが、マクロを使用して概念実証を作成して試してみることができます（基本的に@devecのように）

また、既存の配列理解構文に「適合する」という利点もあります。

result = [g(f(.i), h(.j)) over i, j]

対。

result = [g(f(_i), h(_j)) for _i in eachindex(i), _j in eachindex(j)]

2つの主な違いは、前者はマップを意味するため、形状の保存に関してより多くの制限があることです。

over 、 range 、およびwindowには、反復の修飾子としてOLAPスペースにいくつかの先行技術がありますが、これは一貫しているようです。

.構文は、ラインノイズへの忍び寄りのように見えるので、私は熱心ではありません。

$はおそらく一貫性があり、i、jを式に反復する値をインターンしますか？

result = [g(f($i), h($j)) over i, j]

式の自動ベクトル化の場合、式内のベクトルの1つをtaintして、型システムに式をベクトル空間に持ち上げさせることはできませんか？

私は時系列の操作と同じように、ジュリアの表現力によってすでに書くことができます

ts_a = GetTS( ... )
ts_b = GetTS( ... ) 
factors = [ 1,  2, 3 ]

ts_x = ts_a * 2 + sin( ts_a * factors ) + ts_b 

これは、観測されると時系列のベクトルを出力します。

欠けている主な部分は、既存の機能をスペースに自動的に持ち上げる機能です。 これは手作業で行う必要があります

基本的に、次のようなものを定義できるようにしたいと思います...

abstract TS{K}
function {F}{K}( x::TS{K}, y::TS{K} ) = tsjoin( F, x, y ) 
# tsjoin is a time series iteration operator

その後、特定の操作に特化できるようになります

function mean{K}(x::TS{K}) = ... # my hand rolled form

こんにちは@JeffBezanson 、

私が正しく理解している場合は、上記のコメントに関するJuliaCon2015コメントの解決策を提案したいと思います。
「[...]そして、ライブラリの作成者に@vectorizeをすべての適切な関数に配置するように指示するのはばかげています。関数を作成するだけで、誰かがすべての要素に対してそれを計算したい場合は、マップを使用します。」
（しかし、他の基本的な問題については取り上げません。「[..] sin、expなどを暗黙的に配列にマッピングする必要があるという本当に説得力のある理由はありません。」）

Julia v0.40では、@ vectrorizeよりもいくらか良い解決策を得ることができました（私の意見では）：

abstract Vectorizable{Fn}
#Could easily have added extra argument to Vectorizable, but want to show inheritance case:
abstract Vectorizable2Arg{Fn} <: Vectorizable{Fn}

call{F}(::Type{Vectorizable2Arg{F}}, x1, x2) = eval(:($F($x1,$x2)))
function call{F,T1,T2}(fn::Type{Vectorizable2Arg{F}}, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#Function in need of vectorizing:
function _myadd(x::Number, y::Number)
    return x+y+1
end

#"Register" the function as a Vectorizable 2-argument (alternative to @vectorize):
typealias myadd Vectorizable2Arg{:_myadd}

<strong i="13">@show</strong> myadd(5,6)
<strong i="14">@show</strong> myadd(collect(1:10),collect(21:30.0)) #Type stable!

これは多かれ少なかれ合理的ですが、 @ vectorizeソリューションにいくぶん似ています。 ベクトル化をエレガントにするために、Juliaは以下をサポートすることをお勧めします。

abstract Vectorizable <: Function
abstract Vectorizable2Arg <: Vectorizable

function call{T1,T2}(fn::Vectorizable2Arg, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#Note: by default, functions would normally be <: Function:
function myadd(x::Number, y::Number) <: Vectorizable2Arg
    return x+y+1
end

それでおしまい！ ベクトル化可能な関数から関数を継承させると、ベクトル化可能になります。

私はあなたが探していたものに沿ってこれを願っています。

よろしく、

MA

多重継承がない場合、関数はどのようにしてVectorizableや他の何かから継承しますか？ また、特定のメソッドの継承情報をジェネリック関数の継承情報にどのように関連付けますか？

@ ma-laforgeすでにそれを行うことができます---タイプmyadd <: Vectorizable2Argを定義してから、 Numberのmyaddにcallを実装します。

@JeffBezansonに感謝します！

確かに、私のソリューションは、私が望むものとほぼ同じように見えることができます。

abstract Vectorizable
#Could easily have parameterized Vectorizable, but want to show inheritance case:
abstract Vectorizable2Arg <: Vectorizable

function call{T1,T2}(fn::Vectorizable2Arg, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#SECTION F: Function in need of vectorizing:
immutable MyAddType <: Vectorizable2Arg; end
const myadd = MyAddType()
function call(::MyAddType, x::Number, y::Number)
    return x+y+1
end

<strong i="7">@show</strong> myadd(5,6)
<strong i="8">@show</strong> myadd(collect(1:10),collect(21:30.0)) #Type stable

ここで欠けているのは、関数を「サブタイプ化」する方法だけです。これにより、セクションF全体をより洗練された構文に置き換えることができます。

function myadd(x::Number, y::Number) <: Vectorizable2Arg
    return x+y+1
end

注：呼び出しシグネチャでType{Vectorizable2Arg}を使用する場合よりも結果の構文が優れているため、タイプ「MyAddType」と関数名をシングルトンオブジェクト「myadd」にしました。

function call{T1,T2}(fn::Type{Vectorizable2Arg}, v1::Vector{T1}, v2::Vector{T2})

残念ながら、あなたの回答によれば、これは@vectorizeマクロの「愚かさ」に対する適切な解決策ではないように思われます。

よろしく、

MA

@johnmyleswhite ：

コメントに返信したいのですが、わかりません。 明確にできますか？

私が言うことができる1つのこと：
「Vectorizable」について特別なことは何もありません。 アイデアは、誰でも独自の関数「クラス」を定義できるということです（例： MyFunctionGroupA<:Function ）。 次に、（上記で示したように）独自の「呼び出し」シグネチャを定義することにより、そのタイプの関数への呼び出しをキャッチできます。

私の提案は、Base内で定義された関数は、ベクトル化されたアルゴリズムを自動的に自動生成するためにBase.Vectorizable <: Function （または同様のもの）を使用する必要があるということです。

次に、モジュール開発者が次のようなパターンを使用して独自の関数を実装することをお勧めします。

myfunction(x::MyType, y::MyType) <: Base.Vectorizable

もちろん、デフォルトでMyTypeを返さない場合は、独自のバージョンのpromote_type(::Type{MyType},::Type{MyType})を提供する必要があります。

デフォルトのベクトル化アルゴリズムが不十分な場合、ユーザーが独自の階層を実装することを妨げるものは何もありません。

MyVectorizable{nargs} <: Function
call(fn::MyVectorizable{2}, x, y) = ...

myfunction(x::MyType, y:MyType) <: MyVectorizable{2}

MA

@ ma-laforge、不明で申し訳ありません。 私の懸念は、Juliaには単一の継承があり、関数ごとに単一の親型にコミットする必要があるため、どの階層でも常に重要な情報が不足することです。 myfunction(x::MyType, y::MyType) <: Base.Vectorizableのようなものを使用する場合、nullableの関数を自動生成するBase.NullableLiftableのような概念を定義している他の誰かから、関数は恩恵を受けません。

これは特性の問題ではないようです（https://github.com/JuliaLang/julia/pull/13222を参照）。 また、メソッドを純粋として宣言する新しい可能性（https://github.com/JuliaLang/julia/pull/13555）も関連しています。これは、そのようなメソッドがベクトル化可能であることを自動的に意味する可能性があります（少なくとも単一引数のメソッドの場合）。

@johnmyleswhite 、

私が正しく理解していれば：それは特に_this_の場合には問題ではないと思います。 デザインパターンを提案しているからです。 あなたの関数はBase.Vectorizableから継承する必要はありません...あなたはあなた自身のものを使うことができます。

私はNullableLiftablesについてあまりよく知りません（私のバージョンのJuliaにはそれがないようです）。 ただし、 Base.Functionから継承すると仮定します（これは私のバージョンのJuliaでも不可能です）。

NullableLiftable <: Function

その後、モジュールは_new_vectorizableサブタイプを（1回だけ）実装できます。

abstract VectorizableNullableLiftable <: NullableLiftable

function call{T1,T2}(fn::VectorizableNullableLiftable, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

したがって、これからは、関数<: VectorizableNullableLiftableを定義する人は誰でも、ベクトル化コードが自動的に適用されるようになります。

function mycooladdon(scalar1, scalar2) <: VectorizableNullableLiftable
...

私は理解しています、複数のVectorizableタイプを持つことはまだいくらか苦痛です（そして少しエレガントではありません）...しかし少なくともそれはジュリアの厄介な繰り返し（1）の1つを取り除くでしょう（新しく追加された_each_を登録する必要があります@vectorize_Xargを呼び出して関数を実行します）。

（1）これは、Juliaが関数の継承をサポートしていることを前提としています（例： myfunction(...)<: Vectorizable ）-v0.4.0では表示されません。 Julia 0.4.0で動作するようになった解決策は、単なるハックです...関数を登録する必要があります... @ vectorize_Xargを呼び出すよりもはるかに優れています

MA

私はまだそれが一種の間違った抽象化だと思います。 「ベクトル化」できる、または「ベクトル化」する必要のある関数は、特定の種類の関数ではありません。 _Every_関数をmapに渡すことができ、この動作を提供します。

ところで、私がjb / Functionsブランチで取り組んでいる変更により、 function f(x) <: Tを実行できるようになります（ただし、明らかに、 fの最初の定義に対してのみ）。

わかりました、私はあなたが探しているものをよりよく理解していると思います...そしてそれは私が提案したものではありません。 @johnmyleswhiteが私の提案でも抱えていた問題の一部かもしれないと思います...

...しかし、問題が何であるかを理解した場合、解決策は私にはさらに簡単に見えます：

function call{T1,T2}(fn::Function, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

myadd(x::Number, y::Number) = x+y+1

myaddはタイプFunctionであるため、 call関数によってトラップされるはずです...これは次のように行われます。

call(myadd,collect(1:10),collect(21:30.0)) #No problem

ただし、 callは、何らかの理由で（理由はわかりませんが）、関数を自動ディスパッチしません。

myadd(collect(1:10),collect(21:30.0)) #Hmm... Julia v0.4.0 does not dispatch this to call...

しかし、私はこの振る舞いを変えるのはそれほど難しくないはずだと思います。 個人的には、このような包括的なキャッチオール機能を作ることについてどう思うかはわかりませんが、それはあなたが望んでいることのように思えます。

私が気付いた奇妙なこと： Juliaは、関数が入力されていない場合、すでに関数を自動ベクトル化します。

myadd(x,y) = x+y+1 #This gets vectorized automatically, for some reason

RE：ところで...：
いいね！ 関数をサブタイピングすることで、どのようなすてきなことができるのだろうか:)。

関数が入力されていない場合、Juliaはすでに関数を自動ベクトル化します

関数内で使用される+演算子がベクトル化されているため、このように見えます。

しかし、私はこの振る舞いを変えるのはそれほど難しくないはずだと思います。 個人的には、このような包括的なキャッチオール機能を作ることについてどう思うかはわかりませんが、それはあなたが望んでいることのように思えます。

私はあなたの予約を共有します。 「関数を呼び出す方法は次のとおりです」という定義を賢明に設定することはできません。各関数自体が、呼び出されたときに何をすべきかを示しているからです。これが関数です。

私は言うべきでした：...ユーザーがそのようなコア機能にアクセスするためにユニコード文字を入力することを要求したくないので、ユーザー定義の非ユニコード中置演算子。 $は実際に追加されたものの1つだと思いますが、ありがとうございます。 うわー、これは実際に今日のジュリアで機能します（「高速」ではない場合でも...まだ）：

ジュリア>（$）=マップ
ジュリア> sin $（0.5 *（abs2 $（xy）））

@binarybana ↦ / \mapstoどうですか？

julia> x, y = rand(3), rand(3);

julia> ↦ = map    # \mapsto<TAB>
map (generic function with 39 methods)

julia> sin ↦ (0.5 * (abs2 ↦ (x-y)))
3-element Array{Float64,1}:
 0.271196
 0.0927406
 0.0632608

もあります：

• ⤇ / \Mapsto
• ⟼ / \longmapsto
• ⟾ / \Longmapsto
• ⤅ / \twoheadmapsto
• ⊸ / \multimap （並列マップ？）
• http://julia.readthedocs.org/en/latest/manual/unicode-input

FWIW、少なくとも最初は、 \mapstoはラムダの代替構文であると思います。これは、数学で一般的に使用されており、基本的に（ASCIIの化身では-> ）ジュリアでも使用されているためです。 。 これはかなり紛らわしいと思います。

数学といえば…モデル理論では、括弧なしで関数をタプルに適用することによって表現されるmapを見てきました。 つまり、 \bar{a}=(a_1, \dots, a_n)の場合、 f(\bar{a})はf(a_1, \dots, a_n) （つまり、基本的にapply ）であり、 f\bar{a}は(f(a_1), \dots, f(a_n))です。 map ）。 準同型などを定義するための便利な構文ですが、プログラミング言語に簡単に転送できるわけではありません：-}

\Mapstoのような他の選択肢はどうですか、 => （ペア）と混同しますか？ ここでは、両方の記号を並べて区別できると思います。

• ->
• ↦

似ているシンボルはたくさんありますが、非常に異なって見えるシンボルや純粋なASCIIのシンボルだけを使用する場合、それらのシンボルが非常に多くなる理由は何でしょうか。

これはかなり紛らわしいと思います。

ドキュメントと経験がこれを解決すると思います、あなたは同意しますか？

記号のような矢印は他にもたくさんあります。正直なところ、数学などで何に使われているのかわかりません。名前にmapが含まれているので、これだけを提案しました。 ：笑顔：

私の言いたいことは、 ->はJuliaが↦をASCIIで表現しようとしたことだと思います。 したがって、 ↦を使用して他の何かを意味することは、お勧めできません。 視覚的に区別できないわけではありません:-)

私の直感は、確立された数学記号を使用する場合、少なくともジュリアの使用法が確立された使用法とどのように異なるかを考えたいと思うかもしれないということです。 名前にmapが含まれるシンボルを選択するのは理にかなっているようですが、この場合は、マップ（または異なるタイプのマップ、またはそのようなマップのタイプ）の定義を参照します。 これは、多かれ少なかれペアでの使用法にも当てはまります。ここでは、パラメーターのマップ先を定義して完全な関数を定義するのではなく、特定の引数（パラメーター値）のマップ先を実際にリストします。つまり、明示的にの要素です。概念的に列挙された関数（例：辞書）。

@ Ismael-VC提案の問題は、 mapを2回呼び出す必要があることですが、理想的な解決策は一時的な配列を含まず、 map((a, b) -> sin(0.5 * abs2(a-b)), x, y)に減らすことです。 さらに、 ↦を2回繰り返すことは、視覚的にも入力する場合にも適していません（ASCIIに相当するものがあればよいでしょう）。

Rユーザーはこのアイデアを嫌うかもしれませんが、 ~の現在の中置マクロの特殊なケースの解析を廃止する方向に進むと（GLMやDataFramesなどのパッケージは数式DSLのマクロ解析に変更する必要があります。参照https：/ /github.com/JuliaStats/GLM.jl/issues/116）、これにより、中置asciiオペレーターのまれな商品が解放されます。

a ~ bはベースでmap(a, b)として定義でき、おそらくa .~ bはbroadcast(a, b)として定義できますか？ 従来の中置演算子として解析する場合、JuMPが<=および==で行うように、R式インターフェイスのエミュレーションのようなマクロDSLは、マクロ内で演算子の独自の解釈を自由に実装できます。 。

それはおそらく最も美しい提案ではありませんが、それらを使いすぎるとMathematicaの省略形でもありません...私のお気に入りは.#&/@です

：+1：特別なケーシングを減らし、一般性と一貫性を高めるために、 ~と.~に提案する意味は私には素晴らしいと思います。

+1トニー。

@tkelman明確にするために、たとえばsin(0.5 * abs2(a-b))を完全にベクトル化された方法でどのように記述しますか？

理解して、おそらく。 中置マップがvarargsまたはインプレースで機能するとは思わないので、自由な構文の可能性がすべての問題を解決するわけではありません。

したがって、この問題は実際には修正されません。 ：-/

これまでのところ、 sin(0.5 * abs2(a-b)) over (a, b)構文（または、おそらく中置演算子を使用するバリアント）が最も魅力的です。

この号のタイトルは「 map(func, x)の代替構文」です。 中置演算子を使用しても、マップとループの融合を解決して一時的なものを排除することはできませんが、構文よりもさらに広範で、関連しているが、技術的には別の問題である可能性があります。

はい、 @ tkelmanに同意します。要点は、 mapの代替構文を使用することです。そのため、 \mapsto 、 ↦を使用することをお勧めします。 @nalimilanが言及していることは、より広く、別の問題IMHO、 How to fully vecotrize expressionsにより適しているように思われますか？

<rambling>
この問題は1年以上続いています（そして、他の多くの問題が現在あるように、無期限に続く可能性があります）！ しかし、今はAlternative syntax for map(func, x)になる可能性があります。 ±450人のジュリアンの貢献者のうち、41人だけがこの問題を見つけたり意見を共有したりすることができました（これはgithubの問題にはたくさんありますが、この場合は明らかに十分ではありません）、全体としてそれほど異なる提案はありません（これは、同じ概念の単なるマイナーなバリエーションではありません）。

調査や世論調査（：shocked :)を行うことで、そのアイデアが気に入らなかったり、価値が見られなかったりする人もいますが、このようなことについて誰かに許可を求める必要はないので、とにかくやります。 私たちがコミュニティやソーシャルネットワークを十分に活用していないのはちょっと悲しいことですが、他のコミュニティもその価値を理解していないことをさらに悲しいです、私がもっと異なった新鮮な意見を集めることができるかどうか見てみましょう、または少なくともチェックしてください実験として、この特定の問題の現在の意見について大多数がどのように感じているかを調べ、それがどうなるかを見てください。 多分それは本当に役に立たないかもしれません、多分そうではないかもしれません、本当に知る唯一の方法があります。
</rambling>

@ Ismael-VC：本当に投票をしたいのなら、最初にやらなければならないことは、あなたが聞きたい質問を注意深く検討することです。 全員がスレッド全体を読み、個別に議論するために用意されているオプションを要約することを期待することはできません。

map(func, x)は、 map(v -> sin(0.5 * abs2(v)), x)のようなものもカバーしており、これがこのスレッドで説明されています。 これを別のスレッドに移動しないでください。上記のすべての提案を覚えるのが難しくなります。

mapを使用してジェネリック関数を適用するという単純なケースの構文を追加することに反対していませんが、そうする場合は、より広い視野を同時に検討することをお勧めします。 そうでなければ、この問題はかなり前に修正されていた可能性があります。

@ Ismael-VC世論調査がここで私見を助ける可能性は低いです。 私たちは、いくつかの解決策のどれが最良のものであるかを見つけようとしているのではなく、実際には誰もまだ見つけていない解決策を見つけようとしています。 この議論はすでに長く、多くの人々が関わっています。これ以上追加しても役に立たないと思います。

@ Ismael-VCそれで結構です。気軽に投票してください。 実際、私は過去にいくつかの問題について落書き投票を行いました（例：http：//doodle.com/poll/s8734pcue8yxv6t4）。 私の経験では、問題のスレッドで議論するよりも同じか少ない人が投票に投票します。 これは、非常に具体的な、多くの場合表面的な/構文上の問題に意味があります。 しかし、あなたができることは既存のオプションから選ぶことだけである場合、世論調査はどのように新鮮なアイデアを生み出すのでしょうか？

もちろん、この問題の本当の目標は、暗黙的にベクトル化された関数を排除することです。 理論的には、 mapの構文で十分です。これらの関数はすべて、すべての場合にmapを実行しているだけだからです。

私はこれについて既存の数学表記法を探しようとしましたが、操作は重要ではなく、表記法を使用できないというコメントが表示される傾向があります。 数学的な文脈での任意の関数の場合、私はこれをほとんど信じることができます。 ただし、最も近いのはアダマール積表記であり、いくつかの一般化があります：https： //en.wikipedia.org/wiki/Hadamard_product_ （matrices）#Analogous_Operations

@rfourquetが提案したように、これでsin∘xが残ります。 ユニコードが必要で、とにかく広く知られていないので、あまり役に立たないようです。

@nalimilan 、 sin(0.5 * abs2(a-b)) ~ (a,b)を実行すると、 map((a,b)->sin(0.5 * abs2(a-b)), (a,b))に変換されると思います。 それが正しいかどうかはわかりませんが、うまくいくと思います。

私はまた、let-me-give-you-a-huge-complicated-expression-and-you-perfectly-auto-vectorize-it-for-meの問題を深く掘り下げすぎないように注意しています。 その点での究極の解決策は、式/タスク+クエリプランニングなどのDAGを完全に構築することだと思います。しかし、 mapの便利な構文を使用するよりも、はるかに大きな魚だと思います。

@quinnjええ、中置演算子を除いて、これは基本的に上記で提案されたover構文です。

深刻なコメント：SQLは本質的に、行ごとの「ベクトル化」によって適用される多くの変数の要素ごとの関数を構成するための言語であるため、このアイデアを十分に追求すれば、SQLを再発明する可能性が高いと思います。

@johnmyleswhiteは同意し、DSL別名Linqのように見え始めます

投稿されたスレッドのトピックでは、|> 'パイプ'演算子を特殊化して、マップスタイル機能を取得できます。 関数をデータにパイプするように読み取ることができます。 追加のボーナスとして、同じものを使用して関数の合成を実行できます。

julia> (|>)(x::Function, y...) = map(x, y... )
|> (generic function with 8 methods)

julia> (|>)(x::Function, y::Function) = (z...)->x(y(z...))
|> (generic function with 8 methods)

julia> sin |> cos |> [ 1,2,3 ]
3-element Array{Float64,1}:
  0.514395
 -0.404239
 -0.836022

julia> x,y = rand(3), rand(3)
([0.8883630054185454,0.32542923024720194,0.6022157767415313],    [0.35274912207468145,0.2331784754319688,0.9262490059844113])

julia> sin |> ( 0.5 *( abs( x - y ) ) )
3-element Array{Float64,1}:
 0.264617
 0.046109
 0.161309

@johnmyleswhiteそれは本当ですが、かなり控えめな価値のある中間目標があります。 私のブランチでは、マルチ演算のベクトル化された式のmapバージョンは、現在のバージョンよりもすでに高速です。 したがって、スムーズに移行する方法を見つけることは、やや緊急です。

@johnmyleswhiteわからない。 SQLの多くは、行の選択、順序付け、およびマージに関するものです。 ここでは、関数を要素ごとに適用することについてのみ説明しています。 さらに、SQLは、削減（例： SUM ）と要素単位の操作（例： > 、 LN ）を区別するための構文を提供していません。 後者は、現在のJuliaと同じように、単純に自動的にベクトル化されます。

@JeffBezanson \circを使用することの利点は、インデックス付きファミリーをインデックスセット（標準の数学的「実装」）からの関数として解釈する場合、マッピングは単純な構成であるということです。 つまり、 (sin ∘ x)(i)=sin(x(i)) 、つまりsin(x[i])です。

@mdcfrancisが言及しているように、パイプの使用は本質的に「図の順序」の構成であり、数学（または特に圏論のCSアプリケーション）では（おそらく太い）セミコロンで行われることがよくありますが、すでにパイプがありますもちろん、オペレーター。

これらの合成演算子のどちらも問題がない場合は、他の演算子を使用できます。 たとえば、少なくとも一部の作成者は、抽象的な矢印/射の構成に低い\cdotを使用します。これは、本質的に、矢印の亜群（多かれ少なかれ）の「乗算」であるためです。

また、ASCIIアナログが必要な場合：乗算を示すために実際にピリオドを使用する作成者もいます。 （作曲にも使われているのを見たことがあるかもしれませんが、思い出せません。）

したがって、 sin . xが発生する可能性があります…しかし、それは混乱を招くと思います：-}

それでも…その最後のアナロジーは、本当に初期の提案の1つ、つまりsin.(x)の議論かもしれません。 （または多分それはとてつもないです。）

別の角度から試してみましょう。私を撃たないでください。

..をcollect(..(A,B)) == ((a[1],..., a[n]), (b[1], ...,b[n])) == zip(A,B)で定義すると、正式にT[x,y,z] = [T(x), T(y), T(z)]を使用すると、

map(f,A,B) = [f(a[1],b[1]), ..., f(a[n],b[n])] = f[zip(A,B)...] = f[..(A,B)]

これにより、配列構築の構文に干渉しないマップの構文が少なくとも1つ動機付けられます。 ::またはtableを使用すると、拡張機能f[::(A,B)] = [f(a[i], b[j]) for i in 1:n, j in 1:n]は、少なくとも2番目の興味深いユースケースにつながります。

聞きたい質問を慎重に検討してください。

@toivohありがとうございます。 私は現在、いくつかの投票/調査ソフトウェアを評価しています。 また、私は好ましい構文についてのみポーリングします。スレッド全体を読みたい人はそれを行うだけで、他の誰もそれを行うことに興味がないと仮定しないでください。

誰も実際に見つけていない解決策を見つける

@nalimilan誰も私たちの中にいない、つまり。 ：笑顔：

あなたができることは既存のオプションから選ぶことだけであるとき、世論調査はどのように新鮮なアイデアを生み出すのでしょうか？
問題のスレッドで議論するよりも同じか少ない人が投票に投票します。

@JeffBezansonあなたがすでに投票を行ったと聞いてうれしいです、それを続けてください！

• 世論調査をどのように宣伝してきましたか？
• 私がこれまでに評価した世論調査/調査ソフトウェアから、kwiksurveys.comは、ユーザーが_このオプションのどれも私のためではない_オプションの代わりに自分の意見を追加できるようにします。

sin∘x Unicodeが必要であり、とにかく広く知られていないため、あまり役に立たないようです。

Unicodeがたくさんあるので、それを使用しましょう。タブ補完でそれらを使用するための優れた方法もあります。それを使用することの何が問題になっていますか？わからない場合は、文書化して教育しましょう。存在しない場合は、何が問題になりますか。それを発明しますか？ 他の誰かがそれを発明して使用するのを本当に待つ必要があります。そうすれば、それを先例としてとらえ、その後になって初めてそれを検討することができますか？

∘には前例があるので、問題はそれがUnicodeであるということですか？ なぜ？ それでは、広く知られていない残りのUnicodeをいつ使い始めるのでしょうか。 一度もない？

その論理によれば、ジュリアはとにかく広く知られていませんが、学びたい人はそうします。 私の非常に謙虚な意見では、それは私には意味がありません。

十分に公平です、私は∘に完全に反対しているわけではありません。 かなり基本的な機能を使用するためにUnicodeを要求することは、それに対する1つの印にすぎません。 完全に沈めるには必ずしも十分ではありません。

ASCIIの代替として*を使用/オーバーロードするのは完全にクレイジーでしょうか？ 数学的には理にかなっていると言えるかもしれませんが、その意味を理解するのは難しいかもしれません…（ここでも、 map機能に制限されている場合は、 mapはすでにASCIIの代替手段ですよね？）

\circを使用する利点は、インデックス付きのファミリをインデックスセット（標準の数学的な「実装」）からの関数として解釈する場合、マッピングは単純な構成であるということです。

これを買うかどうかわかりません。

@haydそれのどの部分？ インデックス付きのファミリー（たとえば、シーケンス）は、インデックスセットからの関数として見ることができますか、それともそのマッピングが構成になりますか？ それとも、これはこの場合に役立つ視点ですか？

最初の2つの（数学的な）ポイントはかなり議論の余地がないと思います。 しかし、ええ、私はここでこれを使用することを強く主張するつもりはありません-それは主に「ああ、それはちょっと合っています！」でした。 反応。

@mlhetland |>は->にかなり近く、今日は機能します-また、適切に関連付けられるという「利点」もあります。

x = parse( "sin |> cos |> [1,2]" )
:((sin |> cos) |> [1,2])

@mdcfrancisもちろんです。 しかし、それは私がその頭に概説した構成の解釈を変えます。 つまり、 sin∘xはx |> sinと同等ですよね？

PS：「代数」で失われたかもしれませんが、型付き配列構造で関数を許可するだけで、 f[x,y,z]が[f(x),f(y),f(z)] $になるようにT[x,y,z] $が直接与えられます

map(f,A) == f[A...]

これは非常に読みやすく、構文として扱うことができます。

それは賢いです。 しかし、それを機能させることができれば、 sin[x...]はsin(x)やsin~xなどの冗長性を実際に失うのではないかと思います。

構文[sin xs]どうですか？

これは、構文が配列内包表記[sin(x) for x in xs]に似ています。

@mlhetland sin |> x === map（sin、x）

これは、現在の関数チェーンの意味とは逆の順序になります。 その演算子のより良い使用法を見つけてもかまいませんが、移行期間が必要です。

@mdcfrancisはい、それがあなたが目指していることだと思います。 これは（ @tkelmanが繰り返すように）wrtを逆にします。 私が概説した構成の解釈。

ベクトル化と連鎖を統合するのはかなりクールだと思います。 言葉が最も明確な演算子になるのだろうか。
何かのようなもの：

[1, 2] mapall
  +([2, 3]) map
  ^(2, _) chain
  { a = _ + 1
    b = _ - 1
    [a..., b...] } chain
  sum chain
  [ _, 2, 3] chain
  reduce(+, _)

行の複数のマップを自動的に1つのマップに結合して、パフォーマンスを向上させることができます。 また、マップにはある種の自動ブロードキャスト機能があると想定していることにも注意してください。 最初に[1、2]を_に置き換えると、代わりに無名関数を作成できます。 チェーンにRのmagrittrルールを使用していることに注意してください（チェーンスレッドの私の投稿を参照してください）。

多分これはDSLのように見え始めています。

私はこの問題を長い間フォローしていて、今までコメントしていませんが、これは私見では手に負えなくなり始めています。

私は、マップのクリーンな構文のアイデアを強く支持します。 私は@tkelmanの~の提案が最も好きです。それは、そのような基本的な機能のためにASCII内にとどまるからです。そして、私はsin~xがとても好きです。 これにより、上記で説明したように、非常に洗練されたワンライナースタイルのマッピングが可能になります。 sin∘xの使用もOKです。 もっと複雑なことについては、適切なループの方がはるかに明確である（そして通常は最高のパフォーマンスである）と思う傾向があります。 私はあまり「魔法の」放送が好きではありません、それはコードを追跡するのをはるかに難しくします。 通常、明示的なループの方が明確です。

これは、そのような機能を追加すべきではないということではありませんが、特に（ jb/functionsブランチのテストから）超高速になりそうなので、最初に簡潔で簡潔なmap構文を使用しましょう。 。

jb /関数の効果の1つは、 broadcast(op, x, y)が、 opでブロードキャストを手動で特殊化したカスタマイズバージョンx .op yと同じくらい優れたパフォーマンスを発揮することです。

もっと複雑なことについては、適切なループの方がはるかに明確である（そして通常は最高のパフォーマンスである）と思う傾向があります。 私はあまり「魔法の」放送が好きではありません、それはコードを追跡するのをはるかに難しくします。 通常、明示的なループの方が明確です。

同意しません。 exp(2 * x.^2)は完全に読みやすく、 [exp(2 * v^2) for v in x]よりも冗長ではありません。 ここでのIMHOの課題は、前者（コピーを割り当て、操作を融合しない）を使用させることで、人々をトラップしないようにすることです。このため、低速形式を廃止できるように、十分に短い構文を見つける必要があります。

より多くの考え。 関数を呼び出すときに実行したいことがいくつかあります。

引数なしでループする（チェーン）
連鎖した引数だけをループする（マップ）
すべての引数をループする（mapall）

上記のそれぞれは、次の方法で変更できます。
ループするアイテムをマークする（〜）
ループしないようにアイテムをマークする（[]の追加セット）

統合可能なアイテムは、構文に関係なく、自動的に処理される必要があります。
ループスルーされている引数が少なくとも2つある場合、シングルトン次元の拡張は自動的に行われます。

放送は、次元があった場合にのみ違いを生みます
それ以外の場合は不一致。 だからあなたが放送しないと言うとき、あなたは与えることを意味します
引数のサイズが一致しない場合は、代わりにエラーが発生しますか？

sin [x ...]は、sin（x）やsin〜xなどの冗長性を実際に失います。

また、考えを続けると、マップsin[x...]は[f(x...)]のあまり熱心でないバージョンです。
構文

[exp(2 * (...x)^2)]

または、 [exp(2 * (x..)^2)]のようなものが利用可能であり、実際の暗黙の関数連鎖が導入された場合は自己説明します。

@nalimilanはい、しかしそれは私がループなしで大丈夫だと言った私の「ワンライナー」カテゴリーに当てはまります。

私たちがすべての願いをリストしている間、私にとってはるかに重要なのは、 mapの結果を割り当てやコピーなしで割り当て可能にすることです。 これは、パフォーマンスが重要なコードのループを引き続き好むもう1つの理由ですが、これを軽減できれば（＃249は現在希望に満ちたATMに見えません）、これはすべてはるかに魅力的になります。

マップの結果は、割り当てやコピーなしで割り当て可能になります

これについて少し詳しく説明していただけますか？ mapの結果を確実に変更できます。

彼はmapの出力を事前に割り当てられた配列に格納することを意味していると思います。

はい、正確に。 それがすでに可能であるならば、謝罪。

もちろん。 map!がありますが、ご覧のとおり、＃249はそれを行うためのより良い方法を求めています。

@jtravs LazyArray （https://github.com/JuliaLang/julia/issues/8450#issuecomment-65106563）を使用して上記のソリューションを提案しましたが、これまでのところ、パフォーマンスは理想的ではありませんでした。

@toivoh投稿した後、その投稿にいくつかの編集を加えました。 私が心配していた質問は、ループする引数とループしない引数をどのように把握するかです（したがって、mapallはブロードキャストよりも明確である可能性があります）。 複数の引数をループしている場合は、必要に応じて、シングルトン次元を拡張して同等の配列を生成する必要があると思います。

はいmap!は正確に正しいです。 ここでうまくいった構文糖衣がそのケースもカバーしていればいいのですが。 x := ...がRHSをxに暗黙的にマップすることはできませんか。

マッピングとチェーンを統合したChainMapというパッケージを作成しました。

簡単な例を次に示します。

<strong i="7">@chain</strong> begin
  [1, 2]
  -(1)
  (_, _)
  map_all(+)
  <strong i="8">@chain_map</strong> begin
    -(1)
    ^(2. , _)
  end
  begin
    a = _ - 1
    b = _ + 1
    [a, b]
  end
  sum
end

私はそれについて考え続け、配列理解から派生した配列をマッピングするための一貫したジュリアン構文をついに理解したと思います。 次の提案は、すでに確立されている配列理解言語に基づいているため、ジュリアンです。

1. @Juthoによって実際に提案されたf[a...]から始まり、コンベンション
   ベクトルa、bの場合

f[a...] == map(f, a[:])
f[a..., b...] == map(f, a[:], b[:])
etc

これは新しいシンボルを導入しません。

2.）これに加えて、1つの追加演算子の導入を提案します。_shapepreserving_splatting演算子.. （たとえば）。 これは、 ...が_flat_スパッティング演算子であるため、 aがn次元であっても、 f[a...]は配列ではなくベクトルを返す必要があるためです。 ..選択した場合、このコンテキストでは、

f[a.., ] == map(f, a)
f[a.., b..] == map(f, a, b)

結果は引数の形を継承します。 放送を許可する

f[a.., b..] == broadcast(f, a, b)

書くことを可能にするだろう

sum(*[v.., v'..]) == dot(v,v)

ヒューレカ？

これは式のマ​​ッピングには役立ちませんね。 over構文の利点の1つは、式をどのように処理するかです。

sin(x * (y - 2)) over x, y  == map((x, y) -> sin(x * (y - 2)), x, y) 

それを許可したい場合は、上記の[sin(x.. * y..)]またはsin[x.. * y..]を経由する可能性があります。 関数がコンテナーではなく要素を操作するという視覚的なヒントを与えるので、オーバー構文よりも少し気に入っています。

しかし、 x..が単にxにマップされるように、それを単純化することはできませんか？ したがって、 @ johansigfridsの例は次のようになります。

sin(x.. * (y.. - 2))  == map((x, y) -> sin(x * (y - 2)), x, y)

@jtravsスコープ（ [println(g(x..))]対println([g(x..)]) ）と一貫性[x..] = xのため。

もう1つの可能性は、 x.. = x[:, 1], x[:, 2], etc.を先頭のサブ配列（列）の部分的なスプラットとして、 ..yを後続のサブ配列..y = y[1,:], y[2,:]の部分的なスプラットとして取得することです。 両方が異なるインデックスで実行される場合、これは多くの興味深いケースをカバーします

[f(v..)] == [f(v[i]) for i in 1:m ]
[v.. * v..] == [v[i] * v[i] for 1:m]
[v.. * ..v] == [v[i] * v[j] for i in 1:m, j in 1:n]
[f(..A)] == [f(A[:, j]) for j in 1:n]
[f(A..)] == [f(A[i, :]) for i in 1:m]
[dot(A.., ..A)] == [dot(A[:,i], A[j,:]) for i in 1:m, j in 1:n] == A*A
[f(..A..)] == [f(A[i,j]) for i in 1:m, j in 1:n]
[v..] == [..v] = v
[..A..] == A

（ vベクトル、 A行列）

overの方が好きです。これにより、多くの角かっことドットを導入する代わりに、通常の構文で式を記述できるようになります。

あなたは混乱について正しいと思います、そして私は私の提案を適応させて体系化しようとしました。 みんなの忍耐にさらに負担をかけないように、地図やインデックスなどについての考えを要点https://gist.github.com/mschauer/b04e000e9d0963e40058に書きました。

このスレッドを読んだ後、これまでの私の好みは、単純なものとベクトル化された関数に慣れている人々（「 . =ベクトル化された」イディオムはかなり一般的です）に_both_ f(x^2)-x over x f.(x)を使用することです。より複雑な式の場合f(x^2)-x over x 。

Matlab、Numpyなどから来て、ベクトル化された関数構文を完全に放棄するには、あまりにも多くの人がいます。 ドットを追加するように指示するのは覚えやすいです。 複雑な式を単一のループにベクトル化するための優れたoverのような構文も非常に便利です。

over構文は本当に私を間違った方法でこすります。 理由は私に思い浮かびました。式内の各変数のすべての使用法がベクトル化されているか、ベクトル化されていないことを前提としていますが、そうではない場合があります。 たとえば、 log(A) .- sum(A,1) – logのベクトル化を削除したと仮定します。 また、式で関数をベクトル化することはできません。これは、 exp(log(A) .- sum(A,1))を記述し、 expとlogをベクトル化して、 sumはないですか？

@StefanKarpinskiの場合は、 exp.(log.(A) .- sum(A,1))を実行して、追加の一時的なものを受け入れるか（たとえば、パフォーマンスが重要ではないインタラクティブな使用の場合）、またはs = sum(A, 1); exp(log(A) - s) over A （ただし、 sum(A,1)の場合は正しくありません） sumが純粋であり、ループ/マップから引き上げられました。

私にとって、最優先事項はbroadcast(f, x...)またはmap(f, x...)のf.(x...)構文であり、 @vectorizeを取り除くことができます。 その後、 over （またはその他）のような構文で作業を続けて、 mapと内包表記のより一般的な使用法を省略できます。

@stevengj -はブロードキャストされないため、2番目の例は機能しないと思います。 Aが行列であるとすると、出力は単一行の行列の行列になります。各行は、 Aの要素の対数から1次元に沿った合計のベクトルを引いたものです。 broadcast((x, y)->exp(log(x)-y), A, sum(A, 1))が必要です。 しかし、 mapの簡潔な構文は便利であり、必ずしもbroadcastの簡潔な構文である必要はないと思います。

sinのように歴史的に自動ベクトル化されてきた関数は、新しい構文でも引き続きそうなるのでしょうか、それとも非推奨になるのでしょうか。 f.構文でさえ、概念的なエレガンスの議論に動機付けられていない科学プログラマーの大部分にとっては「落とし穴」のように感じるのではないかと心配しています。

私の考えでは、 sinのような歴史的にベクトル化された関数は、 sin.を優先して非推奨にする必要がありますが、（後続のリリースで完全に削除されるのではなく）準永続的に非推奨にする必要があります。他の科学言語からのユーザーの利益。

f.(args...)に関する1つのマイナーな（？）問題： object.(field)構文はほとんどの場合ほとんど使用されず、あまり苦労せずにgetfield(object, field)に置き換えることができますが、 Base.(:+)(....) = ....の形式のメソッド定義/参照の_lot_であり、これらをgetfieldに変更するのは面倒です。

1つの回避策は次のとおりです。

• Base.(:+)を他のすべてのf.(args...)と同様にmap(Base, :+)に変換しますが、下位互換性のために非推奨のメソッドmap(m::Module, s::Symbol) = getfield(m, s)を定義します
• 構文Base.:+ （現在は失敗しています）をサポートし、 Base.(:+)の非推奨警告でこれを推奨します

もう一度お聞きしたいのですが、これが0.5.0でできることでしょうか？ 多くのベクトル化されたコンストラクターが非推奨になるため、これは重要だと思います。 これで大丈夫だと思いましたが、 int32(a) map(Int32, a) $が少し面倒だと思います。

これは基本的に、この時点で構文を選択するだけの問題ですか？

これは基本的に、この時点で構文を選択するだけの問題ですか？

@stevengjは、彼のPR https://github.com/JuliaLang/julia/pull/15032で.sin(x) sin.(x)を書くことに賛成して良い議論をしたと思います。 ですから、パスはクリアされたと思います。

この構文を複合式に効率的に一般化するソリューションがまだないという事実について、私は1つの予約をしました。 しかし、この段階では、この議論を無期限に解決しないよりも、ほとんどのユースケースをカバーするこの機能をマージしたほうがよいと思います。

@JeffBezansonトリアージの議論中にそれを持ち出すために、これのマイルストーンを0.5.0に戻しています。主に、忘れないようにするためです。

＃15032はcallでも機能しますか？例： Int32.(x) ？

@ViralBShah 、はい。 f.(x...)は、 fのタイプに関係なく、構文レベルでmap(f, broadcast, x...)に変換されます。

これが、 f[x...]のようなものに対する.の主な利点です。これは、他の点では魅力的ですが（パーサーの変更は必要ありません）、 f::Functionでのみ機能します。 f[x...]も、概念的にはT[...]配列内包表記と少し衝突します。 @StefanKarpinskiは角かっこ構文が好きだと思いますが？

（別の例を選択すると、PyCallのo::PyObjectオブジェクトは呼び出し可能であり、Pythonオブジェクトoの__call__メソッドを呼び出しますが、同じオブジェクトがo[...]をサポートする場合もあります。 f[x...]ブロードキャストとは少し衝突しますが、 o.(x...)ブロードキャストでは正常に機能します。）

callはもう存在しません。

（ f.(x...)が.(を.+などの類似物にするという@nalimilanの議論も好きです）

はい、ポイントワイズのアナロジーは私も一番好きなものです。 先に進んでマージできますか？

モジュールを含むgetfieldは、実際の非推奨にする必要がありますか？

@tkelman 、何とは対照的に？ ただし、 Base.(:+) （つまり、リテラルシンボル引数）の非推奨警告は、 getfield Base.:+を提案する必要があります。 （_Update_：メソッド定義を処理するために構文の非推奨も必要でした。）

@ViralBShah 、木曜日のトリアージディスカッションでこれについて何か決定はありましたか？ ＃15032はマージにかなり良い形だと思います。

Viralは電話のその部分を逃したと思います。 私の印象では、複数の人がまだf.(x)の美学について予約を持っており、どちらかを好むかもしれません

1. 概念的にも実装上も単純な中置演算子ですが、私が見ることができるものから利用できるASCII演算子はありません。 ~のマクロ解析を非推奨にするという私の以前のアイデアは、パッケージで置き換える作業が必要であり、このサイクルでそれを試みるにはおそらく遅すぎます。
2. または、ループの融合と一時的なものの排除を容易にする代替の新しい構文。 ＃15032のレベルに近い場所には他の代替手段が実装されていないため、予約が残っているにもかかわらず、それをマージして試してみる必要があるようです。

はい、予約はありますが、現在f.(x)よりも良いオプションはありません。 ~のような任意の記号を選択するよりも良いようです。また、 .* （など）に慣れている多くの人は、それが何を意味するのかすぐに推測できるでしょう。

私がよりよく理解したいことの1つは、人々が既存のベクトル化された定義を.(で_置換_しても大丈夫かどうかです。 交換をするのに十分な人が気に入らなければ、私はもっと躊躇します。

この議論に潜んでいるユーザーとして、私はこれを使って既存のベクトル化されたコードを置き換えたいと思っています。

ループが速いので、読みやすさのために私は主にjuliaでベクトル化を使用します。 ですから、前述のようにexpやsinなどによく使うのが好きです。 私はすでに。^、。*をそのような式で使用しているので、sinに余分なドットを追加します。 exp。 etcは、私にとって本当に自然で、さらに明確に感じます...特に、sin（x）とmap（f、x）を混合する代わりに、一般的な表記法を使用して自分の関数で簡単に折りたたむことができる場合は特にそうです。

言うまでもなく、私は通常のユーザーとして、これがマージされることを本当に望んでいます！

fun.(vec)よりも提案されたfun[vec]構文の方が好きです。
[fun vec]についてどう思いますか？ これはリスト内包表記に似ていますが、暗黙の変数があります。 T[fun vec]を実行できる可能性があります

その構文は、Julia 0.4では、長さが1より大きいベクトルに対しては無料です。

julia> [sin rand(1)]
1x2 Array{Any,2}:
 sin  0.0976151

julia> [sin rand(10)]
ERROR: DimensionMismatch("mismatch in dimension 1 (expected 1 got 10)")
 in cat_t at abstractarray.jl:850
 in hcat at abstractarray.jl:875

[fun over vec]のようなものは構文レベルで変換でき、 [fun(x) for x in vec]を単純化する価値があるかもしれませんが、 map(fun,vec)より単純ではありません。

[fun vec]に類似した構文：構文(fun vec)は無料であり、 {fun vec}は非推奨になりました。

julia> (fun vec)
ERROR: syntax: missing separator in tuple

julia> {fun vec}

WARNING: deprecated syntax "{a b ...}".
Use "Any[a b ...]" instead.
1x2 Array{Any,2}:
 fun  [0.3231600663395422,0.10208482721149204,0.7964663210635679,0.5064134055014935,0.7606900072242995,0.29583012284224064,0.5501131920491444,0.35466150455688483,0.6117729165962635,0.7138111929010424]

@diegozea 、 fun[vec]は、 T[vec]と競合するため、除外されました。 (fun vec)は基本的にScheme構文であり、複数の引数の場合はおそらく(fun vec1 vec2 ...)です...これは他のJulia構文とはかなり異なります。 または、タプル構文と競合する(fun vec1, vec2, ...)を意図しましたか？ また、 fun.(vecs...)を超える利点が何であるかは明らかではありません。

さらに、主な目標は、最終的に@vectorized関数を置き換える構文を使用することであることに注意してください（これにより、「ベクトルで機能する」関数の「祝福された」サブセットがなくなります）。構文は、Matlab、Numpyなどのベクトル化された関数に慣れている人々にとって口当たりが良く/直感的/便利である必要があります。 また、 sin(A .+ cos(B[:,1]))のような式でも簡単に構成できる必要があります。 これらの要件は、より「創造的な」提案の多くを除外します。

sin.(A .+ cos.(B[:,1]))は結局それほど悪くは見えません。 これには、優れたドキュメントが必要になります。 f.(x)は.+ .(として文書化されますか？
.+を廃止して、 +.を優先することはできますか？

# Since 
sin.(A .+ cos.(B[:,1]))
# could be written as
sin.(.+(A, cos.(B[:,1])))
# +.
sin.(+.(A, cos.(B[:,1]))) #  will be more coherent.

@ diegozea 、＃15032にはすでにドキュメントが含まれていますが、追加の提案は大歓迎です。

.+は引き続き.+のスペルになります。 まず、このドットの配置は定着しすぎており、ここでスペルを変更しても十分ではありません。 次に、 @ nalimilanが指摘しているように、 .(は「ベクトル化された関数呼び出し演算子」と考えることができ、この観点から、構文はすでに一貫しています。

（ broadcast （＃4883）での型計算の問題が解決されたら、別のPRを作成して、任意の演算子⧆のa .⧆ b $＃$が単なる砂糖になるようにすることを望んでいます。 broadcast(⧆, a, b)の呼び出しの場合。これにより、 .+などを明示的に実装する必要がなくなります。 +などを定義するだけで、ブロードキャスト演算子が自動的に取得されます。特定の演算子に対してbroadcastをオーバーロードすることにより、BLASの呼び出しなどの特殊なメソッドを実装することもできます。）

また、 sin(A .+ cos(B[:,1]))のような式でも簡単に構成できる必要があります。

f1.(x, f2.(y .+ z))をbroadcast((a, b, c)->(f1(a, f2(b + c))), x, y, z) $として解析することは可能ですか？

編集：私はそれがすでに上で言及されているのを見ます... @ githubによってデフォルトで隠されているコメントで。

@ yuyichao 、＃15032でコメントしたように、関数が@pureとしてマークされている場合（少なくともeltypeが不変の場合）、ループ融合は可能であるように見えますが、これはコンパイラのタスクであり、パーサー。 （ただし、このようなベクトル化された構文は、重要な内部ループから最後のサイクルを絞り出すよりも便利です。）

ここでの主な目標は、 @vectorized関数の必要性を排除することであることを忘れないでください。 これには、少なくとも同じくらい一般的で、ほぼ同じくらい便利で、少なくとも同じくらい速い構文が必要です。 自動ループ融合は必要ありませんが、将来のループ融合の可能性を開くために、ユーザーのbroadcastの意図をコンパイラーに公開するのは良いことです。

ループ融合も行う場合、何か欠点はありますか？

@yuyichao 、ループ融合ははるかに難しい問題であり、純粋でない関数を脇に置いても常に可能であるとは限りません（たとえば、上記の@StefanKarpinskiのexp(log(A) .- sum(A,1))の例を参照してください）。 私の意見では、それが実装されるのを待つと、おそらく実装されないことになります—これは段階的に実行する必要があります。 ユーザーの意図を明らかにすることから始めます。 将来さらに最適化できれば、すばらしいです。 そうでない場合でも、現在利用可能な少数の「ベクトル化された」関数の一般化された代替品があります。

もう1つの障害は、 .+などが現在broadcast操作としてパーサーに公開されていないことです。 .+は単なる別の関数です。 私の計画は、上記のように、それを変更することです（ broadcast(+, ...) .+砂糖を作ります）。 しかし、繰り返しになりますが、変更が段階的である場合、進歩を遂げるのははるかに簡単です。

つまり、ループ融合が有効であることを証明してループ融合を行うのは難しいので、回路図面の一部としてパーサーに変換を行わせることができます。 上記の例では、次のように書くことができます。 exp.(log.(A) .- sum(A,1))であり、 broadcast((x, y)->exp(log(x) - y), A, sum(A, 1))として解析されます。

.+がまだ同じカテゴリに属していない場合も問題ありません（ボードキャストされていない関数呼び出しが引数に入れられるのと同じように）。これを（ループ融合）で行うだけでも問題ありません。それ以降のバージョン。 私は主に、パーサーでそのような回路図を使用できるかどうか（つまり、あいまいでないかどうか）、およびこのように記述されたベクトル化されたフューズドループを許可することで欠点があるかどうかを尋ねています。

そうすることが有効であることを証明することによってループ融合を行うことは難しい

コンパイラでそれを行うのは難しい（おそらく不可能ではない）ことを意味します。特に、コンパイラで$ broadcastを特別な場合を除いて、コンパイラはbroadcastの複雑な実装を調べる必要があるためです。おそらく悪い考えであり、可能であればそれを避けるべきです...

多分？ これは興味深いアイデアであり、 .(構文をこのように「融合」として定義し、不純な関数に使用しないように呼び出し元に任せることは不可能ではないようです。 最善の方法は、試してみて、ハードケースがあるかどうかを確認することです（現在、明らかな問題は発生していません）が、「非融合」PRの後でこれを行う傾向があります。

私は「非融合」PRの後にこれを行う傾向があります。

特に.+はとにかく処理されないので、完全に同意します。

私はこれを脱線させたくありませんが、 @ yuyichaoの提案は私にいくつかのアイデアを与えました。 ここで強調するのは、どの関数がベクトル化されるかですが、それは常に私には少し見当違いのようです。本当の問題は、どの変数をベクトル化するかであり、結果の形状を完全に決定します。 これが、ベクトル化のために関数をマークするのではなく、ベクトル化のために引数をマークする傾向がある理由です。 引数をマークすると、ある引数をベクトル化するが別の引数はベクトル化しない関数も使用できます。 とは言うものの、両方を持つことができ、このPRは、組み込みのベクトル化された関数を置き換えるという当面の目的を果たします。

@StefanKarpinski 、 f.(args...)またはbroadcast(f, args...)を呼び出すと、引数を_すべて_ベクトル化します。 （この目的のために、スカラーは0次元配列として扱われることを思い出してください。） @ yuyichaoのf.(args...) = _fusedブロードキャスト構文_（私はますます好きです）の提案では、融合は「 func.(args...)以外の式で「停止」します（将来的には.+などを含めるため）。

したがって、たとえば、 sin.(x .+ cos.(x .^ sum(x.^2)))は（ julia-syntax.scm ） broadcast((x, _s_) -> sin(x + cos(x^_s_)), x, sum(broacast(^, x, 2)))に変わります。 sum関数が「融合境界」になることに注意してください。 フュージョンが副作用を台無しにする場合、発信者はf.(args...)を使用しない責任があります。

これでは不十分な例を考えていますか？

私はますます好きです

私はあなたがそれを好きうれしい。 =）

おそらく同じラウンドに属していないさらに別の拡張機能として、 .= 、 .*=などを使用して、インプレース割り当ての問題を解決できる可能性があります（通常の割り当て）

はい、他の操作の融合の欠如は、＃7052の.+=などに対する私の主な反対でしたが、 .=を他のfunc.(args...)呼び出しと融合させることで解決できると思います。 または、 x[:] = ...を融合します。

：thumbsup：この議論には、実際には非常に直交している2つの概念があります。
matlab'yの「融合ブロードキャスト操作」またはx .* y .+ zとapl'yの「製品とzipのマップ」（ f[product(I,J)...]やf[zip(I,J)...]など）。 お互いを超えて話すこともそれと関係があるかもしれません。

@mschauer 、$＃ IとJが同じ形状の場合、 f.(I, J)はすでに（＃15032で） map(x -> f(x...), zip(I, J)と同等です。 また、 Iが行ベクトルで、 Jが列ベクトルである場合、またはその逆の場合、 broadcast実際に製品セットにマップされます（またはf.(I, J')を実行できます）。両方が1d配列の場合は

直交は正しい言葉ではありませんでした、それらは共存するのに十分に異なっています。

ただし、重要なのは、2つのケースに別々の構文は必要ないということです。 func.(args...)は両方をサポートできます。

三頭政治のメンバー（Stefan、Jeff、Viral）が＃15032（マージ対応だと思います）をマージしたら、これを閉じてロードマップの問題を提出し、残りの提案された変更の概要を示します：ブロードキャストタイプの修正-計算、非推奨@vectorize 、 .opをブロードキャストシュガーに変換し、構文レベルの「broadcast-fusion」を追加して、最後にインプレース割り当てと融合します。 最後の2つはおそらく0.5にはなりません。

ねえ、私は15032について非常に幸せであり、感謝しています。しかし、私は議論を否定するつもりはありません。 たとえば、ベクトルのベクトルや同様のオブジェクトは、ジュリアで使用するのはまだ非常に厄介ですが、理解の結果として雑草のように発芽する可能性があります。 シングルトン次元への反復のエンコードに基づかない優れた暗黙の表記法は、たとえば、柔軟なイテレーターや新しいジェネレーター式を使用することで、これを大幅に緩和する可能性があります。

＃16285を支持して、これを閉じることができると思います。