xref https://github.com/JuliaLang/julia/issues/11557#issuecomment -339776065以下、および@ Sacha0のPR＃24389

私はこの効果のために進行中の作業を行っており、翌日か2日で投稿したいと思っています:)。 一番！

私には、 fill(oneunit(T), sz)は、 ones(T, sz)と比較して、読みやすさの重要な損失のように見えます。

oneunit(T)代わりに、通常はリテラルまたは同様にコンパクトなもので十分であるため、 fill(oneunit(T), sz)ように冗長なものを書く必要はめったにないことに注意してください。 配列コンストラクターの将来の変更により、より短い呪文も可能になる可能性があります。 さらに、 fillに移行すると、それが好きになります:)。 一番！

私達はちょうどかどうかを選ぶことができones使用していますoneまたはoneunit 。 onesとzerosは便利な関数と見なす必要があります。これは、より一般的な関数に関して明確な意味がある限り問題ありません。

トリアージごとの計画：来週再検討します。具体的には、 onesとzerosをMATLAB互換性レイヤーに移動し、ベースでfillを優先することを検討します。 一番！

onesとoneunitsは、2つのオプションを区別します。

これとzerosをMATLAB互換性に移行することについて私がどのように感じているかわかりません。 Mathworksが発明したからといって、それが私たちが誇りに思うことができる優れた便利なAPIではないという意味ではありません。 簡単に言えば、この考えの背後にある理由は何でしたか？ （申し訳ありませんが、トリアージははるかに効率的であるように見えますが、推論が与えられていない場合は大幅に透明性が低くなります）。

それは私もわくわくするような変化ではありませんが、論理的な矛盾があるので私はそれを上げました。 ones(T, sz) fill(one(T), sz)意味すると言っても過言ではありませんが、実際にはfill(oneunit(T), sz)です。

1つのオプションは、名前をoneunitsに変更することです。 別の方法は、恐ろしいスワップを行うことです： one -> algebraic_oneおよびoneunit -> one 。 これは壊れており、非推奨を介して行うことはできません。そのため、私は「恐ろしい」と言います。

はい、私は追加することだと思いますoneunitsし、変更ones与えるためにfill(one(T), ...)がない、そのための明白な修正でしょうか？

私はそれで大丈夫だろう。 好奇心から、 fill(one(T), sz)の用途は何ですか？ onesも必要ですか？

ハハ:)私は尋ねるつもりでした-あなたはfill(oneunits(T), sz)を何に使うのですか？ （たとえば、1メートル、1キログラム、または1秒で満たされた配列は何に使用されますか？）

fill(one(T), sz)は、カスタムのreduction-type-of操作用に配列を初期化するzeros(T, sz)とほぼ同じ理由で使用されていると思います。 配列z = zeros(T, sz)は、要素をz[i] += x追加する準備ができていますが、 o = fill(one(T), sz)は、要素をo[i] *= x乗算する準備ができています。 たとえば、配列要素が（相対的な）確率を表す可能性がある状況を考えています。 これらの2つのケースでは、それぞれ+または*演算子のIDを探しています（加法ジェネレーターではありません）。

＃23544も参照してください

ハハ:)私は尋ねるつもりでした-あなたは何のためにfill（oneunits（T）、sz）を使いますか？ （たとえば、1メートル、1キログラム、または1秒で満たされた配列は何に使用されますか？）

ODEの従属変数。 T型の配列を要求したときに、ユニットがランダムに切り刻まれただけだとしたら、それは奇妙なことです。

fillを好む基本的な理由は、強力で直交する構成可能なツールのタイトなセットが、 ones / zerosなどのアドホックで制限された重複するツールの大規模なコレクションよりも優れているためです。 trues / falses 。 上記の説明は、この点を強調しています。 fill上記のすべてのユースケースに明確かつ（ほとんどの実際の使用では）簡潔に対応しますが、 ones / zeros / trues / falsesアプローチでは、ユースケースごとに新しい関数が必要です。

ベースの書き換えからのいくつかの関連する例：

complex.(ones(size(Ac, 1)), ones(size(Ac, 1)))

になります

fill(1.0 + 1.0im, size(Ac, 1))

と

2ones(Int, 2, 2, 2)

になります

fill(2, (2, 2, 2)) # or fill(2, 2, 2, 2) if you prefer

これらのfill呪文は、 fill以外の呪文よりも単純で、読みやすく、コンパクトで、効率的であり、 base/とtest/はこのような例がたくさんあります。 すべての変更と同様に、 fillに移行するには、初期の精神的な調整が必要です。 しかし、調整後は、指先でより多くのパワーとエレガンスを手に入れることができます:)。 一番！

@ Sacha0 ： trues / falsesはfillに直接置き換えることはできませんが、 BitArrayイニシャライザーでfill!を使用する必要があります。 また、 oneとoneunit間のあいまいさにも含まれていません。 したがって、私はそれらがこの議論にまったく当てはまらないと思います。

ones 、とにかく非推奨にすることに一般的に反対していますが、メリットはわかりません。 fillすると、ある式をより効果的に記述できるという議論は、私の意見ではあまり説得力がありません。これらの例はすべて、他のことを行うための中間ステップとしてonesを使用しているためです。 しかし、実際に配列が必要な場合はどうでしょうか。 その場合、 fillを使用する必要があるのは長く、わかりにくく、煩わしいだけです。 @JeffBezansonの提案が一番好きbaseまたはtestを、 ones代わりにfillを使用してより効果的に書き換えることができる場合、現時点ではそれを妨げるものは何もありません。

@carlobaldassiそれは事実ですが、 GitHubをすばやく検索すると、中間の割り当てを回避するために、 onesほとんどすべての使用で実際にfillを使用する必要があることがわかります...

これらの場合にfillを使用することは、私には理にかなっています。 onesなどの対応するメソッドを置き換える新しいfill(x, A) = fill!(x, copymutable(A))メソッドが必要になることに注意してください。

@TotalVerbその検索の最初の10ページの簡単なonesの正当なユースケースがたくさんあり、おそらく大多数です（そして、たとえ20％と言ったとしても、私の主張はまだ有効だと思います）。

（私は実際に読みやすさの議論についても留保しています。たとえば、 fill(2, 2, 2, 2)は2 * ones(Int, 2, 2, 2)よりも読みやすい、またはたとえばfill(k * 1.0, 3)方が読みやすいと主張するのは疑わしいと思います。 k * ones(3)よりも読みやすい;それが単なる習慣の問題であるとはまったく確信していません。しかし、これはマイナーな点です。）

true / falseは、fillで直接置き換えることはできませんが、fillを使用する必要があります。 BitArrayイニシャライザを使用します。 また、1ユニットと1ユニットの間のあいまいさにも含まれていません。 したがって、私はそれらがこの議論にまったく当てはまらないと思います。

実際、 truesとfalsesはfill直接置き換えることはできません:)。 むしろ、 truesとfalsesは、上記の/＃11557に関連する一般的な問題の追加のインスタンスです（そして、配列コンストラクターの最近の方向性がうまくいけば取り組むでしょう）。 他の例としては、BandedMatrices.jlにbones 、 bzeros 、 brand 、 brandn 、 beyeが存在することや、 DistributedArrays.jlのdプレフィックス。

いずれにせよ、私は一般的にそれを非推奨にすることに反対しています、私は利点を見ていません。 これらの例はすべて、他のことを行うための中間ステップとして式を使用しているため、塗りつぶしを使用してより効果的に式を記述できるという議論は、私の意見ではあまり説得力がありません。

ベースでones数百の使用法を書き直したばかりなので、 @ TotalVerbのステートメントを確認できます。

GitHubをすばやく検索すると、中間の割り当てを回避するために、ほとんどすべての用途で実際に塗りつぶしを使用する必要があることがわかります...

（編集：ほぼすべてではなく約半分と言いますが、適切な書き換えはfill以外のものである可能性があります。）さらに、その書き換えの経験は私に教えてくれました...

しかし、実際に配列が必要な場合はどうでしょうか。 その場合、塗りつぶしを使用する必要があり、より長く、目立たなくなり、煩わしくなります。

...一方、その場合、 fillはしばしば短くて単純です：要求されたものはしばしばFloat64はありません（代わりにones(Int, n...)とones(Complex{Float64}, n...) ）、この場合、 fillは、リテラル（たとえば、 fill(1, n...)およびfill(1.0 + 0im, n...) ）を許可することにより、短く簡単になります。 測定可能な用語で言えば、ベースでones呼び出しを書き換えているブランチは、 ones -> fill書き換えから、文字数が最大5％短くなっています。 一番！

onesが実際にどのように表示されるかを客観的に理解するために、GitHub検索の最初の10ページに表示されるすべてのones呼び出しを収集して、Juliaコードでonesを検索しました。そのような各呼び出しは、必要に応じて、対応する変更を分類し（この要点を参照）、分類データを次の要約に減らしました。

分析には、156のones呼び出しが含まれていました。 それらの呼び出しのうち、

• 84回の呼び出し（〜54％）はアドホックfill 。 （たとえば、 ones(100)/sqrt(100)*7はfill(7/sqrt(100), 100) ones(100)/sqrt(100)*7簡略化されますが、さらに良いのはfill(.7, 100)です。私のお気に入りはkron(0.997, ones(1, J*J*s) -> fill(0.997, 1, J*J*s) 。）

• 3回の通話（〜2％）はアドホックブロードキャストでした。 （たとえば、 A - ones(n,n)はA .- 1.簡略化されます。）

• 5回の呼び出し（〜3％）は、アドホックなベクトルリテラルでした。 （たとえば、 ones(1)は[1.]簡略化されます。）

• 1回の呼び出し（〜0.5％）は、意味的にはジャンクマトリックス構造でした。 （実際には比較的まれですが、このパターンはtest/非常に一般的です。これは、たとえば<strong i="32">@test_throws</strong> DimensionMismatch BLAS.trsv(...,Vector{elty}(n+1))と<strong i="34">@test_throws</strong> DimensionMismatch BLAS.trsv(...,ones(elty,n+1)) 、初期化されていないArrayの簡潔な便利なコンストラクターがないためです。 <strong i="34">@test_throws</strong> DimensionMismatch BLAS.trsv(...,ones(elty,n+1)) 。）

残りの呼び出しはonesとして意味的に合理的oneが特に必要であるという理由ではなく、単に短いという理由だけでonesが使用されることがよくあります。 それらの残りの呼び出しのうち、

• 13回の呼び出し（〜8％）は、 fillわずかに短かった。 （たとえば、 ones(Int, n, n) -> fill(1, n, n)またはones(Float64, n) -> fill(1., n) 。）

• 50回の呼び出し（〜32％）は、 fillわずかに長くなりました。 （たとえば、 ones(n, n) -> fill(1., n, n) 。）

全体として、実際には、 ones呼び出しの約60％は他の方法で記述した方が適切であり、約8％は意味的にonesあり、 fillとわずかに短く、 ones 、 fillより少し長くなります。

追加の観察：

配列引数を受け入れるones呼び出しのインスタンスが1つだけ発生しましたが、それを囲むスニペットが実際のコードであるかどうかは明確ではありませんでした。 したがって、配列引数を受け入れるonesメソッドは、実際にはほとんど使用されません。

本当に興味深い議論...また別の言語の先例として、Rは、使用しています...側のために側に対してであることから行ってきましたrepとmatrixと等価である方法で、 fill （1dと2dの場合に対応）そしてあなたは非常にすぐにそれに慣れます-私がゼロ/ワンの世界から来たとしても。

うわー、その努力をしてくれてありがとう@ Sacha0 ！

当然、「 zerosどうですか？」という質問が発生します。 使用量が大幅に増え、使用カテゴリがいくつか増えると思います（「初期化されていない配列を信頼しない」、「 Arrayコンストラクターの使用方法がわからない」など）。 "）。

何らかの理由で（私はそれがの対称性だと思うoneとzero ）、Iはやや両方交換する方に惹かonesとzerosとfill 、またはどちらでもない。

ゼロの場合は、次のいずれかの状況にあるように見えるということです。

1. ほとんどのゼロを上書きする必要があります。この場合、理解度を使用することをお勧めします。
2. ほとんどのゼロを置き換える必要はありません。この場合、スパース行列を使用することをお勧めします。
3. 実際には、すべてゼロの行列が必要です。この場合は、 0Iを使用することをお勧めします。

密なゼロの行列を実際に割り当てることが実際に良い考えであるというユースケースは実際にはありません。

それはおそらく線形代数にも当てはまります。 コンパイラやその他のデータ構造に関する私の作業で、ゼロで初期化されたコレクションが必要になることは珍しくありません。 たぶんそれらはまばらであることが多いですが、それらをコンパクトに表現することはパフォーマンスに影響を与える価値がありません。

十分に公平です–密度を気にしない場合があり、単純さはそれだけの価値があります。

トリアージ：完全に非ジェネリックなメソッド、つまりzeros(dims...)とones(dims...) 、おそらくzeros(dims)とones(dims)も保持することを解決しました。

使用方法推奨事項については@StefanKarpinskiはそれがどういう意味をお勧めでしょうzeros(3, 3)の上にfill(0.0, 3, 3) （密な配列は、などなどたかったされている場合）通常のコードのために？ 効率性などの詳細のいくつかは私の手の届かないところにあります、私は前進するジュリアでどのようにベスト/イディオムの実践を教えるかを考えています。

この決定は私には非常に驚くべきことのように思われます。一般性を具体的に妨げることは基本的にそれほど一般的ではありません。 背後にある理由は何ですか？ この関数は、ジェネリックではない（そして、floatでのみ機能する）matlabからのものですか？

トリアージ：完全に非ジェネリックなメソッドのみを保持することを解決しました

背後にある理由は何ですか？

これに加えて、この問題は、現在検討されていると思われる配列を構築する一般的な問題に何らかの形で関連していますか？もしそうなら、これはどのように役立ちますか？ または、エクスポートされるメソッドの数をBaseから削減しようとしていますか？ （または完全に何か他のもの？）

https://github.com/JuliaLang/julia/issues/24595で近日公開予定:)。 一番！

24595のOPは、この問題のより広範なコンテキストを詳しく説明しており、＃24595のフォローアップでは、コンビニエンスコンストラクターones 、 zeros 、およびfillについて詳しく説明しています。 前者を読むことは、後者を理解する上で価値があります。 一番！

まあ、少なくともFloat64場合を保存することは、何もないよりはましです。
整数のゼロの場合も非常に関連性があると思います。これは、基本的に@vtjnashがここで作成したポイント

zerosは、 3 * ones(n)アンチパターンを許可するという「問題」がないことにも注意してください。 実際、便利なコンストラクターであるという広い意味を除いて、 onesとzerosが一緒になる理由はよくわかりません。 これら2つの間に実際の「対称性」はありません。

統計分析に関するいくつかの追加のコメント。これは、以下の議論と＃24595の記述の基礎であるように思われるためです。 まず、10ページでは、実際に何が起こっているのかをきめ細かく結論付けるには十分ではなく、せいぜい大まかなアイデアを与えることができます。 たとえば、名前やスタイルから明らかなように、一部のファイルはmatlabから直接取得されました。 第二に、私が推測したように、その分析でさえ、そこでのonesの使用の約半分が「正当な」ものであったことを示しています。 第三に、このようなコードを見ても、 3 * ones(...)書くときに何もわかりませんが、実際にはパフォーマンスの問題を引き起こすアンチパターンであるか、パフォーマンスにまったく影響を与えないコードです（そしてライターはそのように書かれている方が読みやすいと判断しました。その場合、他の人が他の方法で決定することはないと強く感じています）。

最後のポイントに関連して、そしてもっと重要なことに、github検索から得られるものは、ジュリアで探索的/予備的な作業をしている人々のREPLで何が起こっているかを決して考慮に入れていないと思います。 これはまさに便利な機能が最も便利な場所であり、認識できる理由なしにそれらを取り除くことはそれに応じて最も厄介です。 私のポイントは、一般的で効率的なコードを書くことを可能にする直交プリミティブの一貫したセットを持つことは大きな目標であり、そこに到達するための努力は本当に称賛に値します。 すべてのコードが美しく、一般的で、構成可能なライブラリコードであるとは限らないというだけです。 ちょうど私の2セント。

それにかんする

整数のゼロの場合も非常に関連性があると思います。これは、基本的に@vtjnashがここで作成したポイントです。

これは

コンパイラやその他のデータ構造に関する私の作業で、ゼロで初期化されたコレクションが必要になることは珍しくありません。 たぶんそれらはまばらであることが多いですが、それらをコンパクトに表現することはパフォーマンスに影響を与える価値がありません。

その場合、 fillも同様またはそれ以上に機能することに注意してください： fill(0, shape...)対zeros(Int, shape...) 。

他の点に関しては、＃24595は読む価値があるかもしれません:)。 一番！

zeros(Int, 10, 10)はfill(0, 10, 10)よりも読みやすく、明示的であり、 zeros(T, k)はfill(zero(T), k)よりも優れていることがわかりました。 なぜ私たちは両方を持つことができないのですか？ zerosがonesと同じあいまいさの問題を抱えているという議論は買いません。

他の点については、＃24595を読む価値があるかもしれません

私はそれを読んだ。 （私もそれをリンクしました。）

私はそれを読んだ。 （私もそれをリンクしました。）

＃24595を完全に読み、十分に検討すると、＃24595が次のことに気付くでしょう。（1）便利なコンストラクターが一部にすぎないというはるかに広範な問題に関係している。 （2）上記の統計分析と、ここで焦点を当てるポイントだけではありません。

onesとzerosについて強く感じていただきありがとうございます。 あなたの感情は大声ではっきりと伝わってきました:)。 そのため、現在の形でこの会話を続けるよりも、他の分野を前進させるために帯域幅を費やしたほうがよい可能性があります。 一番！

zeros変更に伴う一般的なfill着信はありますか？ zerosは、 similarよりもはるかに安全であるため、ジェネリックプログラミングに非常に合法的に使用されていたため、DiffEqはすべて、最近、OptimとNLsolveがsimilar割り当てからzerosすべてがゼロを持つように割り当てられていることを知っているので、多くのバグを防ぐことができます。 ただし、次の方法はないようです。

zeros(X)

もう、以外：

similar(X); fill!(X,0)

現在のfillはArray fillのみをビルドするため、 similarやzerosようにタイプマッチしません。 zerosを悪用して、必要のないときに割り当てる人もいることは知っていますが、多くの場合、 zeros割り当てるのは非常に合理的なことです。 この空白を埋めるためにfill(0,X)速記が追加されることを願っています。

思いやりのある投稿クリスに感謝します！ :)暫定的な速記の代わりとして、 zero(X)はトリックを行いますか？

このようなユースケースが正確であることを注意における曖昧zerosおよびones問題となり得る。ずにzeros(X)収率でオブジェクトeltype(X)を充填eltype(X)の加法単位元（つまりfill!(similar(X), 0) ）、または代わりにeltype(X)乗法ゼロで満たされたオブジェクト（おそらくeltype(X) ）？ （拡張については、＃24595を参照してください。）

fill(0, X)概念は、＃11557で少し議論されていますが、それがfill有用な一般化である可能性があることに同意します。 ありがとう、そして最高！

もう1つの問題は、型にはまらないインデックスを持つ配列をzeros(inds...)ようなもので作成したい場合があることです（インデックスタイプが配列タイプを決定するため）。 しかし、1次元の場合、 X 「類似させたい配列」ですか、それとも「目的の配列のインデックス」ですか？ （結局のところ、 AbstractUnitRange <: AbstractArrayです。）具体的には、 zeros(3:5)はfill!(similar(3:5), 0)またはfill!(OffsetArray(Vector{Float64}(3), 3:5), 0)意味しますか？

https://github.com/JuliaLang/julia/pull/24656をリンクし{ones|zeros }(A::AbstractArray, ...)コンビニエンスコンストラクターの追加の説明が含まれています。 一番！

＃24656に従ってキャッシュ変数を作成するためにzerosを使用するのは奇妙だと考えられていることに驚いています。 zerosがゼロに近いオーバーヘッドに削減された場合、人々がsimilarを使用しているほとんどの場合は、代わりにzerosになるはずです。これは、かなりの数を修正する傾向があるためです。バグ。 similarは非常に危険であり、関数がなく、代わりにfill! + similarをまとめると、それがわかりにくくなるため、より多くの人にこれを行うように勧めるべきだと思います。人々がすべきこと。 Optim.jlでポップアップするこれについてのコメントは次のとおりです。

https://github.com/JuliaNLSolvers/NLsolve.jl/issues/89#issuecomment -294585960

しかし、私は@timholyに同意し

https://github.com/JuliaDiffEq/MultiScaleArrays.jl

MultiScaleArrays.jlは、微分方程式ソルバーで使用できる再帰的なグラフのような構造である抽象配列を作成しました（そして、Optim.jlおよびNLsolve.jlと互換性があると思いますか？）。 これは、とりわけ生物学的モデルにとって非常に便利です。 それをODEソルバーに投げ込むとき、質問があります：キャッシュ配列を何にすべきですか？ 場合によっては、ユーザーが必要な配列を取り戻すことが重要です。これは、ODE関数f(t,u,du)表示され、それに応じて処理したい場合があるためです。 ただし、それ以外の場合は、内部でブロードキャストされたものとしてのみ表示されます。 したがって、2つの異なるタイプのキャッシュ変数があります。

これを処理するには、次のいずれかのアルゴリズムのキャッシュを確認してください。

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/caches/low_order_rk_caches.jl#L224 -L234

ここで、 rate_prototype = similar(u,first(u)/t,indices(u)は似ていますが、ユニットのeltypeが異なる可能性があります。 ただし、ここには2つの異なるタイプがあることに注意してください： similar(u)とsimilar(u,indices(u)) 。 私はそれらを「タイプと形状を一致させる」対「形状とエルタイプを一致させるが、同じタイプである必要はない」という意味であると解釈しました。 したがって、 AbstractMultiScaleArray場合、最初のものは別のAbstractMultiScaleArrayを作成し、もう1つは、ユーザーに表示されないため速度を上げるために、適切なArrayを作成します。サイズ。 次に、これはsimilar(u,T)とsimilar(u,T,indices(u))拡張されます。

たぶんそれはすでに存在するものを駄洒落にしているだけですが、これは重要な違いだと思います。 ジェネリックプログラミングを行う場合、2つの別々のキャッシュがあります。タイプを期待に一致させるために必要なユーザー向けキャッシュと、アルゴリズムによって使用されるだけで可能な限り高速にする必要がある内部キャッシュです。

zerosバージョンを思い付くのが面倒だったので、これらがsimilarを使用していることに注意してください。 ユーザーがf(t,u,du)微分計算でduのみを設定した場合、「設定しないことは意味する」と暗黙的に言う傾向があるため、実際にはこれらの配列の一部をゼロにすることができる別の場所があります。ゼロ」、これはzerosで割り当てられた場合にのみ当てはまるので、可能な限りzerosを使用して事前割り当てを試みます（これについてはNLsolve.jlでも同じ問題が発生します） 。

うまくいけば、その説明は従うのにそれほど混乱していませんでした。 私の場合はすべて、 similar続けてfill!に切り替えることができますが、一部のパッケージは切り替えられず、それがバグの原因になることはわかっています。

面白い。 similar(A, inds)がsimilar(A)とは異なるタイプを作成する可能性があることは確かですが、一般的には、同じタイプを異なるインデックスで作成する可能性が高いと常に考えていました。 たとえば、2次元オブジェクトの列方向の操作に1次元のキャッシュが必要な場合は、 similar(A, first(inds))ます。 （もちろんの次元がタイプパラメータであるため、それは別のタイプであるが、それは同じ抽象コンテナタイプかもしれません。）また、小さなタイルなどの5x5のキャッシュを作成するためにそれを使用することができます

全体として、これは難しい問題のようです。 ゲームの後半ですが、 sameを導入する必要がありますか？ similarと同じ引数を持つことができますが、契約では、同じ抽象コンテナーを返す必要があります。

same 1つの引数形式をサポートできますが、これでも注意が必要です。 aがsetindex!サポートしていない場合、 same(a)は同じ配列型を返すことができないことに注意してください。 sameとsimilarは、後で配列に書き込む場合にのみ役立つため、 setindex! 。 不変のa場合、これをエラーにすることができますが、 AbstractArrayインターフェイスとして、これは正しい汎用コードを作成するために不要（そしておそらく役に立たない）のようです。

同様に、すべてのAbstractArrayが異なるeltypeまたはインデックスをサポートできるとは限りません。 私にとって、2つまたは3つの引数形式のsameがあると、多くの場所で実行時エラーが発生するだけで、一般的なコードがどのAbstractArrayでもうまく機能するという誤った安心感を人々に与えます。

しかし、1次元の場合、Xは「類似させたい配列」ですか、それとも「目的の配列のインデックス」ですか？

これは、 keysが同じインデックスと値を持つコンテナを返し、これをsimilar要件にすることに賛成するもう1つの理由です（で1つの整数を指定しない限り）この場合、 Base.OneTo （CartesianRange）が想定されます）。

この議論は＃18161に向かって進んでおり、おそらくそこで継続する必要があります:)。

最近のトリアージは、 ones維持することに傾いていました。

それらを維持することは痛いですか？ ずんぐりした出身の人がジュリアでくつろげるのに役立つと思います。

onesとzerosます。