Julia: ブロードキャストには1つの仕事がありました（たとえば、イテレータとジェネレータを介したブロードキャスト）

これは意図的なものです。 broadcastは形状のあるコンテナ用で、デフォルトではオブジェクトをスカラーとして扱います。 mapは形状のないコンテナ用であり、デフォルトではオブジェクトをイテレータとして扱います。

たとえば、 broadcastは文字列を「スカラー」として扱いますが、 mapは文字を繰り返し処理します。

おそらく問題は、人々が新しいドット構文があまりにも便利だと感じることです。 しかし、過去にはmapをコンパクトに表現したいという要望がありました。 残念ながら、ドット構文はすでに採用されています。

また、 @ stevengjが以前に指摘したように、 mapとbroadcast間には違いがあるはずですが、そうでない場合は、両方を持つことのポイントは何ですか。

@stevengjしかし、イテレーターには形があります（特にジェネレーター） http://docs.julialang.org/en/release-0.5/manual/interfaces/#interfaces

イテレータがこの厄介な領域にあることは、イテレータでも実行したいコンテナで実行したいことのほとんどであると私は主張します。そうです、おそらく.構文があまりにも便利であるという事実だけです。 （そしてあなたが得るエラーは非常に不透明です）。

@pabloferz mapとbroadcastの主な違いは、スカラーの扱いです。 現在、スカラーの定義については議論の余地があり、 length(x) > 1を持つすべてのものをスカラーと見なすべきではないと思います。

関数呼び出し自体ではなく、どの引数を反復可能として扱うかをマークすると、あいまいさがなくなります。 私が思うに？

broadcast （私は一般的にも信じています）が形をしているということは、 size （ lengthだけでなく）を持ち、索引付け可能であることを意味します。 タプルを除いて、 sizeないものはすべてスカラーとして扱われます。 現在の実装を考えると、最初にgetindex必要であるか、ブロードキャストするオブジェクトに対して1つを定義できる必要があります。 イテレータの場合、これは一般的には不可能です。

私もこれに出くわしました。 （固定値ではなく）関数の評価を繰り返して配列をfill!する方法を探している＃16769から来て、ドット構文ですでにうまくいくのではないかと思いました。 しかし、 a = zeros(2, 3); a .= [rand() for i=1:2, j=1:3]機能する場合、（おそらく）より安いa .= (rand() for i=1:2, j=1:3)は機能しません。 このジェネレーターはHasShape()ですが、実際にはインデックス作成機能はありません。 ブロードキャスト/ドット構文がどのように機能するかについての理解は非常に軽いですが、ここでインデックス作成機能の特性を持っていると役に立ちますか？ そのためのPR（＃22489）がすでにあります...

@rfourquet 、あなたはa = zeros(2, 3); a .= rand.()行うことができます

はい。ただし、もっと正確に言う必要があります。 a .= (f(i, j) for i=1:2, j=1:3)ように、インデックスをパラメーターとして取得する関数を使用したいと思います。

HasShapeイテレータのブロードキャストディメンションの欠点は何でしょうか？ それは自然なことのように聞こえます。

@nalimilan 、一見したところ、それは合理的で、おそらく比較的簡単に実装できると思います。 壊れているので、1.0までに行う必要があります。

これに関する潜在的な問題の1つは、 HasShapeイテレータが必ずしもgetindexサポートしているとは限らないことです。これにより、実装が難しくなる可能性がありますか？

1つの可能性は、一時的に（1.0の場合）配列にコピーしただけの単純な実装を作成することです。 これにより、1.0以降の最適化が可能になります

これに関する潜在的な問題の1つは、HasShapeイテレータが必ずしもgetindexをサポートしていないことです。これにより、実装が難しくなる可能性がありますか？

上で述べたように、イテレータへのインデックス作成を可能にするPRが＃22489にあります。これが役立つ場合は、

少なくとも1.xの動作を改善するには、1.0で何をする必要がありますか？

それを@nalimilanに感謝します、私もそれをやりたかったのです。 ブロードキャスト式の右側でHasShapeジェネレーターを許可することが1.0に実装できない場合、ジェネレーターをスカラーとして扱うのではなく、今すぐこれをエラーにする必要がありますか？ これを1.xで有効にできるようにします。

：+1：トリアージでは、これをエラーにするか（安全な選択）、 collectを呼び出すことをお勧めします（簡単な場合）。

mapは、すべての引数をコンテナーとして扱い、すべての引数を反復処理しようとします。 私の理想的な世界では、 broadcastは似ており、そのすべての引数がブロードキャスト可能な形状を持っていることを扱い、たとえばsizeが定義されていない場合はエラーが発生します。 ブロードキャストでは、値をfillでラップして、0-d配列を生成することにより、任意の値をスカラーとして扱うことができることを指摘します。

julia> fill("a")
0-dimensional Array{String,0}:
"a"

julia> fill([2])
0-dimensional Array{Array{Int64,1},0}:
[2]

デフォルトですべてのスカラーをコンテナーとして扱うことを本当に提案しますか？ それはあまり実用的ではないようです。

イテレータをサポートする方法、またはサポートするまでエラーをスローする方法を見ると、 BroadcastStyleイテレータを識別する方法が必要なようです。 Symbolようなスカラーに対しても、 Base.iteratorsizeはHasLength返すため、現在は不可能です。 Base.isiterableトレイト（他のことに役立つ可能性があります）を導入するか、 Base.iteratorsizeデフォルトでNotIterableすることができます（これはHasLengthを持つことにも意味があります）デフォルトとしての

（将来の議論のためのトリッキーなケース： UniformScaling 。）

@timholy broadcastの再設計を行ったので、何か提案はありますか？

@JeffBezanson 、 broadcast要点は、コンテナに一致するようにスカラーを「ブロードキャスト」できることです。たとえば、 ["bug", "cow", "house"] .* "s" ----> ["bugs", "cows", "houses"]ます。 これは、 mapの動作とは根本的に異なります。

これが、 broadcastがデフォルトでオブジェクトをスカラーとして扱い、コンテナと組み合わせることができる理由です。 認識されないタイプに対してエラーをスローすると、その有用性が大幅に低下します。

特定の型をbroadcastコンテナーとして宣言するには、適切なメソッドを定義する必要がありますが、デフォルトでは引き続きオブジェクトをスカラーとして扱う必要があると思います。

無関係のPR（https://github.com/JuliaLang/julia/pull/25339）で、 @ Kenoはapplicable(start, (x,))を使用して、 xが反復可能かどうかを確認することを提案しました。 ここでも同じアプローチを使用する必要がありますか？ イテレータをより明確に定義する方が明確だと思いますが（ Base.iteratorsizeまたは特性に基づく）、 startを使用することも理にかなっています。

デフォルトがapplicable(start, (x,))ある明示的な特性を持つことができます。 これにより、必要に応じてオーバーライドできます。

考えられる解決策とその欠点を説明するために、＃25356を提出しました。

@stevengjの例["bug", "cow", "house"] .* "s" ----> ["bugs", "cows", "houses"]から、文字列は反復可能ですが、そこではスカラーのように機能するため、反復可能性は十分ではないようです。 とにかく特性を定義する必要がある場合は、すべてのイテレータに要件を追加するのではなく、ブロードキャストのオプトインを引き続き要求するのが最善の場合があります。

幸い、 keys(dict)はAbstractSet返すようになったため、 AbstractSetブロードキャスト特性を追加すると、OPの例が修正されます。 いくつかの一般的なケースをキャッチするために、 Generatorをブロードキャストするためのエラーを追加することもできます。

AbstractSetコンテナーを介したブロードキャストは、本質的に少し問題があるようです。 AbstractSetをスカラーと組み合わせることができますが、セットの反復順序が指定されていないため、他のコンテナーと組み合わせることができません。 この種の操作は、「ブロードキャスト」操作の通常の意味を破ります。

はい、PRを準備するときに、セットはブロードキャストをサポートする必要があるイテレータの最良の例ではないことに気付きました。 GeneratorやProductIteratorものは、はるかに興味深いケースです。

たぶん答えは、 HasShapeを持つイテレータをブロードキャストし、それ以外はすべてスカラーとして扱い続けることです。 OPは修正されませんが、それ以外はかなりエレガントです。

他のランダムな考え：形状の互換性は問題ではないので、1つの引数（ string.(x) ）をブロードキャストすることは、 mapように機能する特殊なケースである必要がありますか？

たぶん答えは、HasShapeを持つイテレータをブロードキャストし、他のすべてをスカラーとして扱い続けることです（しようとしますか？） OPは修正されませんが、それ以外はかなりエレガントです。

HasLengthイテレータを除外する強い理由があるかどうかはわかりません。 タプル（ size実装していない）を介したブロードキャストをサポートしているので、形のないイテレーターをタプルのように扱ってみませんか？ 例えば、それは結果を使用できるようにするには完璧な理にかなってkeys(::OrderedDict)してbroadcast 。 サポートされていない場合、 broadcast （および素敵なドット構文）で使用できるようにするために、イテレータをHasShapeとして定義したくなるでしょう。

スティーブを引用すると、

broadcastは形状のあるコンテナ用です

HasShapeは、それをより正確に定義するための合理的な方法のようです。 そうでなければ、たとえば文字列でのブロードキャストの動作を中断する必要があるように思われます。

タプルはコンテナーと見なされ、文字列はスカラーと見なされるため、すでに矛盾があります。 とにかく文字列は非常に特別です。文字列の動作が形状を持たないためではないと思います。文字列が、コンテナよりもスカラーと見なされることが多い唯一のコレクションであるという事実に関連しています。

たぶん@stevengjは、 broadcastが形状のあるコンテナーのみをサポートする必要があると彼が考える理由を開発できますか？ タプルをスカラーと見なすこともサポートしますか？

タプルをbroadcast （＃16986）でコンテナーとして扱う理由は、実際にはタプルは本質的に静的なベクトルとして使用されることが多く、 broadcastでは「スカラー」として扱うことはなかったためだと思います。とにかくとても便利です。 対照的に、文字列は（a）文字列処理操作の「アトム」として扱われることが多く、（b）一般に連続したインデックスがないため、 broadcastフレームワークへの適合性が非常に低くなります。

原則として、 broadcastコンテナーとして使用されるHasShapeイテレーターをサポートします。 上で述べたように、主な問題は、 HasShapeがあるからといって、 getindex機能することを保証するものではないということです。

上で述べたように、主な問題は、HasShapeを使用してもgetindexが機能することを保証できないことです。

＃22489のようなものが役立ちますか？つまり、イテレータがインデックス可能かどうかを示すイテレータ特性がありますか？

＃22489のようなものが役立ちますか？つまり、イテレータがインデックス可能かどうかを示すイテレータ特性がありますか？

しかし、 broadcastでサポートされるのは、インデックス可能なイテレータだけですか？ これは制限が厳しすぎるように聞こえます。反復可能なもの（たとえば、 keys(::OrderedDict)の結果）に対してstring.(itr, "1")ようなことを実行できると非常に便利であり、それを実装するためにインデックス付けは必要ありません。 0.7 / 1.0でインデックス作成をサポートしていないすべてのイテレータに対してエラーをスローし、後続のリリースでそれらをサポートしようとする方がよいと思います。 とにかく、イテレータをスカラーとして扱うことはあまり役に立ちません。 次に、1.xリリースで必要な動作を実装できます。

@stevengj文字列とタプルに関するあなたの議論に同意しますが、なぜHasLengthイテレータをタプルとして扱うべきではないのですか？ 私は今までこれの正当化を読んでいませんでした。

@nalimilan 、 broadcastでサポートする必要があるのはindexable + hasshapeイテレータだけだと思う​​傾向があります。 一般的なイテレータをこの関数に詰め込もうとすると、その意味が混乱しすぎます。ある時点で、 map使用する必要があります。

イテレータに対してstring.(itr, "1")を実行できると非常に便利です…とにかく、イテレータをスカラーとして扱うことはあまり役に立ちません。

文字列の場合はこれと矛盾します— "1"引数自体はあなたの例では反復可能です。 物事のトンは、（例えば反復可能ですPyObject sのPyCallで定義start順不同のセットのようなものを含め、など）をbroadcast概念が本当に壊れています。

また、＃24990を使用すると、 mapが現在よりもさらに簡単になります。たとえば、 map(string(_,"1"), itr)を実行できるようになります。

@nalimilan 、私は、

現在、インデックス可能なイテレータの特性はありません。 どのようにそれを渡すことを提案しますか？ 私のWIPPR＃25356は、インデックス作成をサポートしていないイテレータに対してエラーをスローします。これは、イテレータをスカラーとして扱うことがあまり役に立たないと仮定すると、それほど悪くはありません。 それらをスカラーとして扱いたい場合は、別の特性が必要ですよね？

私は完全に明白ではないすべてのケースでエラーを発生させる傾向があるので、必ずしもあまり有用ではないデフォルトの動作に自分自身をロックするのではなく、将来的に任意の動作を実装できます（つまり、一部のイテレータをスカラーとして扱います） 。 この問題が示すように、 broadcastの動作は、正しく設計するのに時間がかかります。

（FWIW、 PyObjectは、Pythonイテレータをラップするかどうかを事前に知らないという理由だけで、IIUCが反復プロトコルを実装しているため、私には良い例のようには思えません。 PyObjectは、標準のJuliaオブジェクトのように表示するためにgetfieldオーバーロードを使用する必要があるのと同様に、ここでは明らかに例外です。セットは、よりJulianの例です。）

他の場所で提案されているように、インデックス可能なHasShapeイテレータの特性を追加できます。

トリアージは、ブロードキャストをすべての引数（マップなど）で反復し、演算子文字を追加して（別の号で以前に提案されたようにconst & = Refを実行する、またはおそらく~ ）、明示的にマークするというアイデアが好きです。 0-d引数。

@vtjnash 、それはHasShapeイテレータにとってもどういう意味ですか？ 文字列やセットなどを繰り返しブロードキャストするということですか？ 現在のbroadcast実装は、 getindexと密接に関連しています…特に、異なる次元の引数を組み合わせる場合に、 getindexなしで実装する方法について考えましたか？

理論的には、インデックス付けできないイテレータ（少なくとも意味のある順序を持つイテレータ）をサポートできるはずです。 すべての入力が同じ形状の場合、これは簡単です。 それらが異なる形状であり、イテレータが結果とは異なる（小さい）形状である場合、いくつかの中間ストレージが必要になります。

PR https://github.com/JuliaLang/julia/pull/22489のIteratorAccessトレイトを適応/再利用して、インデックス可能なイテレーターを検出できるようです。 https://github.com/JuliaLang/julia/pull/24774では、どのイテレータがインデックス可能であるか（したがって、 keys実装する必要があるか）を知ることも必要です。

Cc： @rfourquet

👍トリアージでは、これをエラーにする（安全な選択）か、コレクトコールを呼び出す（簡単な場合）ことをお勧めします。

トリアージは、ここで採用する特定の戦略を決定できますか？ たとえば、上記の@JeffBezansonのコメントの「これ」は何ですか？ インデックス作成をサポートしていないすべてのイテレーターに対してエラーをスローする必要がありますか（後で必要なことをすべて実行できるように、現時点で最も安全な選択です）、または一部のイテレーターをスカラーとして扱う必要がありますか？ インデックス可能なイテレータのトレイトを追加する必要がありますか？はいの場合、どのような形式で追加しますか（ Base.IteratorSize新しいトレイトと新しい選択）？ 一般にイテレータの特性を追加する必要がありますか（スカラーと区別できるようにするため）？

次の動作は良いようです。

• デフォルトでは、すべての引数を繰り返してブロードキャストしてみてください。
• それが何らかの理由で機能しない場合は、エラーを出します。
• Ref(x)または[x]を渡して、 Ref(x) xをスカラーとして処理するように強制します。
• エラーを発生させる代わりに、新しいタイプをスカラーとして処理できるように定義できるトレイトを追加します。 これは、反復するか反復しないかを選択するために使用しないでください。 エラーをスカラー動作に変えるだけです。

最後の点（おそらく例を挙げて）のメモを明確にしていただけますか？ 特性が存在することの意味はわかりませんが、反復するか反復しないかを選択するために使用されません。

したがって、基本的に「すべての引数を繰り返してブロードキャストする」とは、コレクション以外のすべての型（特に、 Number 、 Symbolに対してScalar()を返すようにBroadcastStyleを定義する必要があることを意味します。 SymbolとAbstractString ）？ これは、最後の箇条書きで言及されている「特性」のように聞こえます。

正直なところ、非相互作用/スカラーの特性を定義するよりも、反復可能の特性を定義する方がコストがかからないことがわかります。 コレクション以外のすべてのタイプは、ある時点でそのScalar特性を実装するのではないかと思います。これは、一部の（場合によってはまれな）ケースで役立つ可能性があるためです。

それは最後の弾丸が言及している「特性」のように聞こえます

いいえ、最後の箇条書きは、何かが反復を実装する場合、ブロードキャストがそれを反復することを意味します–スカラー特性はなくなります。 いくつかの一般的な明確に反復不可能なタイプ（ TypeやFunctionサブタイプなど）の場合、 MethodError変換するNotIterable特性が必要になる場合があります。 MethodErrorを1つの値（そのオブジェクト）を生成する反復に変換します。 なぜこれが必要だったのか、実際には覚えていません。

つまり、基本的に「すべての引数を繰り返してブロードキャストする」ということは、コレクション以外のすべての型（特に、Number、Symbol、AbstractString）に対してScalar（）を返すようにBroadcastStyleを定義する必要があることを意味しますか？ これは、最後の箇条書きで言及されている「特性」のように聞こえます。

いいえ、 Numberすべてのスカラーサブタイプはそれ自体を反復するため、問題ありません。 シンボル用に定義する必要があります。 AbstractStringはコレクションとして機能します。

型をスカラーとして扱うためのメソッドを定義する必要がある設計は嫌いです。 それがデフォルトであるはずです。 また、文字列をブロードキャストのコンテナとして扱うべきではないと思います。

私はまだ、ブロードキャストはHasShapeイテレータのみをコンテナとして扱うべきだと思います。 これは最初から放送のデザインと一致しています。 何が問題なのですか？

それに関する問題はOPの問題です。 形状のないイテレータがある場合、それをスカラーとして扱うと、おかしな答えが得られます。

また、提案の「特徴」の部分を削除できれば幸いです。 誰も文句を言わない

julia> map(string, [1,2], :a)
ERROR: MethodError: no method matching start(::Symbol)

おそらく、OPの結果が予期しない理由は、_all_引数をスカラーとして扱うブロードキャスト呼び出しを実際に意図している人がいないためです。 引数が1つだけで、それをコレクション/イテレータとして扱う方法がまったくない場合は、ほぼ確実にユーザーが意図しているものです。 もちろん1 .+ 1は引き続き機能するはずですが？

それは私には起こりましたが、1つの議論を特別な場合にするのは混乱しているようです。

次の非対称性が見られます。イテラブルをスカラーとして扱うと、本当に奇妙な結果が得られますが、スカラーをイテラブルとして扱うとエラーが発生します。 エラーが発生した場合は、引数をラップすることで簡単に修正できます。 一方、最初のケースでは、引数を反復処理するためにできる簡単なことは何もありません。

私はまだ、ブロードキャストはHasShapeイテレータのみをコンテナとして扱うべきだと思います。 これは最初から放送のデザインと一致しています。 何が問題なのですか？

@stevengj何が問題なのかというと、完全に合理的な動作を実装できると、一部の操作が機能しなくなるということです。 HasLengthイテレータを、現在特殊なケースであるTupleと同じように扱います。 現在サポートしていなくても、1.xのある時点でサポートできる可能性を残したいと思います。

誰も文句を言わない

ジュリア> map（string、[1,2] 、： a）
エラー：MethodError：start（:: Symbol）に一致するメソッドがありません

@JeffBezanson OTC、私はbroadcastの現在の動作をサポートします。これ:a 、必要に応じてDataFrame列の名前を変更する場合などに非常に役立ちます。 broadcastを変更して、 mapようなエラーをスローすることをお勧めしますか？

次の非対称性が見られます。イテラブルをスカラーとして扱うと、本当に奇妙な結果が得られますが、スカラーをイテラブルとして扱うとエラーが発生します。 エラーが発生した場合は、引数をラップすることで簡単に修正できます。 一方、最初のケースでは、引数を反復処理するためにできる簡単なことは何もありません。

簡単ですが、かなり不便です。 エラーを発生させるのではなく、スカラーをデフォルトでブロードキャストする必要があるという@stevengjに同意します。 もちろん、 Numberタイプは反復可能であるため、煩わしさが常に表示されるとは限りませんが、 Symbol例が示すように、一般的にはあまり役に立ちません。 Charは別のものであり、パッケージで定義された多くのカスタム型もこれに悩まされます（そして、 BroadcastStyleをScalar()として定義することになります）。

問題の核心は、コレクションとスカラーを区別する特性がないことだと思います。 したがって、最も直接的な解決策は、 HasShapeイテレーターをコレクションとして扱い、他のタイプをスカラーとして扱うことHasLengthイテレーターを含みます）。 個人的には、コレクション/イテラブルにトレイトを導入することは非常に理にかなっていると思いますが、それを行う準備ができておらず、イテラブルを検出するために定義されているstartに依存できない場合は、現在の動作を維持する必要があるのではないかと心配しています。

https://github.com/JuliaLang/julia/issues/18618#issuecomment -360594955でのJeffの提案には、 SymbolとCharを「スカラー」タイプとして処理するブロードキャストを許可する余地があります。動作にオプトインする必要があります。 デフォルトでは、 start実装していないため、エラーになります。

ここで最も説得力のある部分は、「コレクション」タイプの唯一の賢明な定義は、それが反復可能であるということです。 はい、それは文字列がコレクションであることを意味します。 時々それらはそのように使われます！ それで、人々がコールサイトで他にオプトインすることを簡単に可能にする振る舞いをデフォルトにしましょう。

しかし、ここには疣贅があります。 数値は反復可能であるため（ HasShapeさえ）、ゼロ次元のコンテナーとして扱われます。 つまり、論理的な結論として、 1 .+ 2 != 3です。 代わりにfill(3, ())になります。

編集：スレッドをさらに脱線させないようにするために、談話に移動しました：

https://discourse.julialang.org/t/lazycall-again-sorry/8629

＃18618（コメント）でのJeffの提案には、SymbolとCharを「スカラー」タイプとして処理するブロードキャストを許可する余地があります。動作にオプトインする必要があります。 デフォルトでは、startを実装していないため、エラーになります。

ええ、私の立場は、スカラーがより自然なフォールバックであるという仮定に基づいています。特に、コレクションはいくつかのメソッド（反復、場合によってはインデックス付け）を実装する必要がありますが、スカラーは単なる「残り」であり、共通点はありません。 最終的には、どのタイプでも必要な動作を実装できますが、可能な限り便利で論理的にする必要があります。これにより、特に不整合を回避できます（たとえば、宣言されてスカラーとして動作するタイプとそうでないタイプがあります）。

他のタイプのルールが明確である限り、文字列や数値などの必須タイプにいくつかの例外があることについてはあまり心配していません。

私は反復とインデックス付けのインターフェースについて少し考えてきました。 反復できる（ただし、インデックスを付けることはできない）便利なオブジェクト、インデックスを付けることができる（ただし、反復できない）オブジェクト、およびその両方を行うオブジェクトがあることに注意してください。 それに基づいて、私は疑問に思います：

• map強く反復プロトコルに結びつけることができた-我々が怠惰作ることができるという有効なようだout = map(f, iterable)任意のためにiterableように例えばfirst(out)ですf(first(iterable))と同じであり、この一般的なレイジー操作が役立つ可能性があるように思われます。
• broadcastは、インデックスインターフェイスに強く結びついている可能性があります- out[i]がf(indexable[i])と同じになるように、怠惰なout = broadcast(f, indexable)を作成できることは有効なようです。この一般的な怠惰な操作が役立つ可能性があるように私には思えます。 明らかに、複数の入力を持つbroadcast 、今でもすべての凝ったことを行うことができます。 ブロードキャストの目的では、スカラーはインデックス付けできないものです（または、 NumberとRefとAbstractArray{0}ように簡単にインデックス付けできます）。

また、1つの引数mapと1つの引数broadcastが、反復可能でインデックス付け可能なコレクションに対して非常に類似した処理を実行することが望ましいと思います。 ただし、 AbstractDict反復がgetindexとは異なるものを返すという事実は、ここでの優れた統合をブロックしているようです。 ：frowning_face :(他のコレクションタイプは問題ないようです）

（私には、文字列のようなものを["bug", "cow", "house"] .* ("s",)ように明示的にラップする必要があるかもしれないという事実は、ここでは大したことのようには聞こえません。3ベクトルについて考えたいときに同じ問題があります。 「単一の3Dポイント」であり、処理するのはそれほど難しくありません（xref＃18379））。

broadcastはインデックス付け可能なコンテナ用である必要があることに同意しますが、文字列を除いて、連続してインデックス付け可能である必要があると思います。 たとえば、 collect(eachindex("aαb🐨γz"))は[1, 2, 4, 5, 9, 11]を提供しますが、これはインデックス作成に基づくbroadcast実装ではうまく機能しません。

しかし、インデックス可能なコンテナを使用するということは、基本的に、コンテナがオプトインするための特性を必要とするということです。これは基本的に私が提唱してきたことです。

連続したインデックスが適切な制約であるかどうかはわかりません。たとえば、辞書には任意のインデックスがあります。

ただし、 broadcast(f, ::String)は新しいStringを作成できず、UTF-8文字幅がf （その保証を行うには、 AbstractDict{Int, Char}ようなものに変換する必要がありますが、これは実際にはあまり役に立たないようです！）。 Stringインデックスは、意味的に重要なインデックスというよりも、高速ルックアップの「トークン」に似ていると言っても過言ではありません（たとえば、同等のUTF-32文字列に変換すると、インデックスが変更されます）。

特性を介してブロードキャスト動作をオプトインしてもかまいません。 一般的なbroadcast(f, ::Any)がどのように動作するかを想像することは、 broadcast(f, ::AbstractDict)ようなものの実装を導く良い方法であると言っているだけです（そして、＃25904で提起した質問に自然に答えます。キーと値のペアではなく、ディクショナリ値）。

人々はこの変化に本当に満足していますか？ 私は、形状のないコンテナを介してブロードキャストする必要はありませんでしたが、常にスカラーとして扱われるべきものをブロードキャストし

私はスカラーとして扱われるべきものを_常に_放送しています。

それらの種類は何ですか？

何でもかまいません。 たとえば、最適化モデルタイプModelと決定変数タイプVariableを定義するパッケージでは、解いた後に値を取得するx::Vector{Variable}がある場合があります。関数value(::Variable, ::Model)::Float64を使用してmodelをモデル化します。 以前は、次のように行うことができました。

value.(x, model)

引数の型が他のパッケージからのものである場合もよくあるので、それらの型のbroadcastableにメソッドを追加すると、その場合は型の著作権侵害になります。 したがって、 Refまたは1要素のタプルを使用する必要があります。 これは克服できないことではありませんが、私の意見では、比較的あいまいな使用パターンをサポートするために、一般的なケースのエレガントさが大幅に低下します。

はい、私はあなたの主張を理解しています、そして私はそれがそのような状況で迷惑であることに同意します。 とは言うものの、古い振る舞いは絶対に問題がありました—それは「デフォルトのフォールバックが場合によっては明らかに間違っている」ものの1つでした。

つまり、誤ったフォールバックを回避する4つのオプションがあります。

1. ブロードキャスト方法を説明するメソッドを実装するには、_everything_が必要です
2. デフォルトでは、物事をコンテナとして扱い、コンテナ以外の場合はエラー/非推奨にします。
   
   
   
   • 未知のオブジェクトをiterateしようとすると、スカラーでエラーが発生します
   
   
   • スカラーには2つのエスケープハッチがあります。ユーザーは呼び出しサイトでそれらをラップでき、ライブラリの作成者はラップされていないスカラーのようなブロードキャストにオプトインできます。
   
   
3. デフォルトでは、物事をスカラーとして扱い、不明なコンテナーのエラーを処理します
   
   
   
   • スカラーに対してのみ定義された関連するメソッドがないことを考えると、 iterateがメソッドエラーをスローすることを表明する必要があります。 それは遅くて遠回りです。
   
   
   • カスタムコンテナでエラーが発生しないように使用できるエスケープハッチは1つだけです。ライブラリの作成者は、ブロードキャストを明示的にオプトインします。 これは、主な目的がコンテナーを操作することである関数にとってはかなり逆に思えます。
   
   
4. applicable(iterate, …)を確認し、それに応じて動作を切り替えます
   
   
   
   • これは現在、start / next / doneからの非推奨メカニズムのために機能せず、一般に、メソッドをメンバーに延期するラッパータイプでは間違っている可能性があります。
   
   

オプション1は誰にとっても悪いことであり、オプション2は現状であり、オプション3は逆方向であり、オプション4はこれまでに行ったことのないものであり、バグが発生する可能性があります。

議論の一部は舞台裏で行われたに違いないと思いますが、このスレッドとhttps://github.com/JuliaLang/julia/pull/25356でnalimilanに対して見た議論には確信が持てません。 stevengjの位置。

カスタムコンテナでエラーが発生しないように使用できるエスケープハッチは1つだけです。ライブラリの作成者は、ブロードキャストを明示的にオプトインします。 これは、主な目的がコンテナーを操作することである関数にとってはかなり逆に思えます。

これが私の意見の相違の主なポイントです。 私には、すべてのJuliaコードで# of iterator types << # of types that should be treated as scalars in a broadcast situation < # of broadcast callsように見えます。 したがって、「余分な」何かを実行する必要がある回数が、ブロードキャストコールの数ではなく、イテレータタイプの数に比例する場合はそれをお勧めします。 また、ライブラリの作成者がイテレータを定義する場合、もう1つのメソッドを定義するように依頼するのは完全に不合理ではありませんが、すべてのパッケージの作成者に、反復不可能なすべての型に対してBase.broadcastable(x) = Ref(x)を定義するように依頼するのは完全に不合理です。 broadcast呼び出しの高い割合で、醜い（IMHO） Ref避けます。

反復を定義するために実装する単一のメソッドがあることは素晴らしいことですが、新しい特性のために、または新しいイテレーターのためにBase.iteratorsizeを指定する必要があるようにするためにもう1つ実装することはそれほど多くの作業ではありません（そして問題のあるHasLengthデフォルトを取り除きます）。 フォールバックbroadcastableメソッドは、その特性に基づくことができます。 または、単一のメソッドで反復を定義することに本当に夢中になっている場合は、 https：//github.com/JuliaLang/のように、明示的なトレイトをデフォルトでapplicable(iterate, ...)にすることができます（post-deprecation-removal） 。 julia / issues / 18618＃issuecomment -354618742、必要に応じてそのデフォルトをオーバーライドするだけです。 Stringようなコーナーケースも、必要に応じてbroadcastableさらに特殊化することで処理できます。

これは事実上0.6の設計であり、この問題が発生し、＃26421と＃19577と＃23197と＃23746などが発生しました。これを検索するのは困難です。

これは、Baseが、オブジェクトのクラス全体に対して正しくないデフォルトのフォールバックを提供していることを意味します。 だから私は、何らかの方法でオプトインしない限りエラーが発生するメカニズムを好みます。 それは意見があり、移行は苦痛ですが、それはあなたに明確にすることを強制します。

イテレータのようなカスタムタイプよりも「スカラーのような」カスタムタイプの方が多いのは正しいかもしれませんが、私はブロードキャストが何よりもまずコンテナでの操作であるという事実を支持しています。 f.(x)は、 f(x)だけでなく、ある種のマッピングを行うことを期待しています。

そして最後に、スカラーデフォルト処理を取得するコンテナは、ブロードキャストで要素ごとに使用することはできません。 たとえば、 Stringは、スカラーのように動作するように特別にケースに入れられたコレクション型です。 状況によっては意味があるように見えますが（たとえば、 isletter.("a1b2c3") ）、「手を伸ばして」要素ごとに作業することはできません。 これが非対称性の議論です。実際にブロードキャスト可能なコレクションにcollectするよりも、Refでコンテナーをより効率的にラップして、コンテナーをスカラーとして扱うことができます。

これらが主な議論です。 Refの醜さに関しては、私は完全に同意します。 解決策は＃27608です。

けっこうだ。 私はそれらの問題に対するノックダウンの議論や魔法の解決策を持っていません、そしてhttps://github.com/JuliaLang/julia/pull/27608は物事を改善するでしょう。

@tkoolen私は同じ懸念とユースケースを持っていました。

指定された引数@mbauman上記説得力十分ではないかもしれません。 より完全にするための2つの質問があります。

1） broadcastable反復可能にするために必要なインターフェースにすることは可能です。
これは完全に体系的であり、開発者に考えさせるでしょう
イテレータがブロードキャストの下でどのように動作するか。
collect(x)として設定することをお勧めすると、ほとんどの場合、移行が比較的簡単になります。
パフォーマンスの低下はありませんよね？

2）つまり、 xがスカラーとしてブロードキャストされた場合、 f.(x)エラーが発生するという意志に要約されます。
「 'f'のすべての引数がスカラーとしてブロードキャストされる」など、 f.(x, y, z)リンター警告/エラーが発生しないのはなぜですか？

とにかく、＃27563を修正して（たとえば＃27608で）、1.0より少し前にユーザーに試してもらうのが賢明かもしれません。
[0.7および1.0.0-rc1.0は修正なしでリリースされました]。

とにかく、＃27563を修正して（たとえば＃27608で）、1.0より少し前にユーザーに試してもらうのが賢明かもしれません。
[0.7および1.0.0-rc1.0は修正なしでリリースされました]。

1.0がリリースされたというニュースを見逃したと思います。

@StefanKarpinski確かに