Julia: 브로드캐스트에는 하나의 작업이 있습니다(예: 반복자와 생성기를 통한 브로드캐스트).

이것은 의도적입니다. broadcast 는 모양이 있는 컨테이너용이며 기본적으로 개체를 스칼라로 처리합니다. map 는 모양이 없는 컨테이너용이며 기본적으로 객체를 반복자로 처리합니다.

예를 들어 broadcast 는 문자열을 "스칼라"로 취급하는 반면 map 는 문자를 반복합니다.

아마도 문제는 사람들이 새로운 점 구문이 너무 편리하다고 생각한다는 것입니다. 하지만 과거에는 map 를 간결하게 표현하고자 하는 바람이 있었습니다. 불행히도 점 구문은 이미 사용 중입니다.

또한 @stevengj 가 이전에 지적했듯이 map 와 broadcast 사이에는 차이가 있어야 합니다. 그렇지 않다면 둘 다 갖는 의미가 무엇입니까?

@stevengj 그러나 Iterator는 모양(특히 생성기)을 가지고 있습니다. http://docs.julialang.org/en/release-0.5/manual/interfaces/#interfaces

나는 반복자가 이 어색한 영역에 있다고 주장하고 싶습니다. 컨테이너로 하고 싶은 대부분의 일이며, 반복자로도 하고 싶은 일이며, 아마도 순전히 . 구문이 너무 편리하다는 사실일 것입니다. (그리고 당신이 얻는 오류는 매우 불투명합니다).

@pabloferz map 와 broadcast 의 주요 차이점은 스칼라 처리입니다. 이제 스칼라의 정의는 논쟁의 여지가 있으며 length(x) > 1 가 있는 모든 것을 스칼라로 간주해서는 안 됩니다.

함수 호출 자체 대신 반복 가능한 것으로 처리할 인수를 표시하면 모호성이 제거됩니다. 제 생각에는?

broadcast (일반적으로 저도 믿습니다)의 경우 모양이 있다는 것은 size ( length 뿐만 아니라)를 갖고 있고 인덱싱할 수 있음을 의미합니다. 튜플을 제외하고 size 가 없는 다른 것은 스칼라로 처리됩니다. 현재 구현이 주어지면 먼저 getindex 하거나 브로드캐스트하려는 개체에 대해 정의할 수 있어야 합니다. 반복자의 경우 일반적으로 불가능합니다.

나도 이것에 부딪쳤다. #16769에서 고정 값 대신에 함수를 반복적으로 평가하여 배열을 fill! 하는 방법을 찾고 있는데 점 구문이 이미 트릭을 수행할 수 있다고 생각했습니다. 그러나 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까지 완료해야 합니다.

이것의 잠재적인 문제 중 하나는 HasShape 반복자가 반드시 getindex 지원하지 않고 구현하기 까다로울 수 있다는 것입니다.

한 가지 가능성은 일시적으로(1.0의 경우) 방금 배열에 복사한 간단한 구현을 만드는 것입니다. 그러면 최적화 포스트 1.0이 허용됩니다.

이것에 대한 한 가지 잠재적인 문제는 HasShape 반복자가 반드시 getindex를 지원하지 않으며 구현하기가 까다로울 수 있다는 것입니다.

위에서 말했듯이 #22489에 PR이 있어 이것이 도움이 될 경우 반복자에 대한 인덱싱을 허용합니다.

최소한 1.x에서 동작을 개선할 수 있도록 1.0에서 수행해야 하는 작업은 무엇입니까?

@nalimilan이 문제 를 제기해 주셔서 감사합니다. 저도 그렇게 하고 싶었습니다. 브로드캐스트 표현식의 오른쪽에 HasShape 생성기를 허용하는 것이 1.0에 대해 구현할 수 없는 경우 생성기를 스칼라로 처리하는 대신 지금 이것을 오류로 만들어야 합니까? 1.x에서 활성화할 수 있습니다.

:+1: Triage는 이것을 오류로 만들거나(안전한 선택) collect 를 호출할 것을 권장합니다(쉬운 경우).

map 는 모든 인수를 컨테이너로 취급하고 모든 인수에 대해 반복을 시도합니다. 내 이상적인 세계에서 broadcast 는 비슷할 것이며 모든 인수가 브로드캐스트할 수 있는 모양을 가지고 처리하고 size 가 정의되지 않은 경우 오류를 제공합니다. 모든 값을 fill 로 래핑하여 브로드캐스트에서 스칼라로 처리할 수 있으며 0차원 배열을 생성합니다.

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

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

기본적으로 모든 스칼라를 컨테이너로 처리하도록 제안하시겠습니까? 별로 실용적이지는 않습니다.

iterable을 지원하거나 지원할 때까지 오류를 발생시키는 방법을 살펴보면 BroadcastStyle 에서 iterator를 식별하는 방법이 필요한 것 같습니다. 현재 때문에, 불가능이 Base.iteratorsize 반환 HasLength 도 같은 스칼라에 대한 Symbol . 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 가 영업 이익의 예제를 해결하는 것입니다. 몇 가지 일반적인 경우를 포착하기 위해 Generator 를 브로드캐스트하는 오류를 추가할 수도 있습니다.

AbstractSet 컨테이너를 통한 브로드캐스팅은 본질적으로 약간 문제가 있는 것 같습니다. AbstractSet 를 스칼라와 결합할 수 있지만 반복 순서가 세트에 대해 지정되지 않았기 때문에 다른 컨테이너와는 결합할 수 없습니다. 이러한 종류는 "브로드캐스트" 작업의 일반적인 의미를 깨뜨립니다.

네, PR을 준비하면서 set이 방송을 지원해야 하는 iterator의 가장 좋은 예가 아니라는 것을 깨달았습니다. Generator 및 ProductIterator 것은 훨씬 더 흥미로운 경우입니다.

아마도 대답은 HasShape 가 있는 반복자를 브로드캐스트하고 다른 모든 것을 스칼라로 계속 처리하는 것입니다. OP를 수정하지는 않지만 그렇지 않으면 꽤 우아합니다.

다른 임의적인 생각: 아마도 하나의 인수를 통해 브로드캐스팅하는 것( string.(x) )은 모양 호환성이 문제가 아니기 때문에 map 처럼 작동하는 특별한 경우여야 합니다.

아마도 대답은 HasShape가 있는 반복자를 브로드캐스트하고 다른 모든 것을 스칼라로 계속 처리하는 것입니까? OP를 수정하지는 않지만 그렇지 않으면 꽤 우아합니다.

HasLength 반복자를 제외할 강력한 이유가 있는지 잘 모르겠습니다. 우리는 튜플을 통한 브로드캐스팅을 지원합니다( size 구현하지 않음). 따라서 형태가 없는 반복자를 튜플과 같이 취급하지 않는 이유는 무엇입니까? 예를 들어, keys(::OrderedDict) 와 함께 broadcast keys(::OrderedDict) 의 결과를 사용할 수 있다는 것은 완벽합니다. 우리가 그것을 지원하지 않는다면, 사람들은 broadcast (그리고 좋은 점 구문)과 함께 사용하기 위해 반복자를 HasShape 로 정의하고 싶어할 것입니다.

스티브의 말을 인용하자면,

broadcast 는 모양이 있는 컨테이너용입니다.

HasShape 는 그것을 보다 정확하게 정의하는 합리적인 방법인 것 같습니다. 그렇지 않으면 예를 들어 문자열에 대한 브로드캐스트 동작을 중단해야 할 것 같습니다.

튜플은 컨테이너로, 문자열은 스칼라로 간주하는 등 이미 불일치가 있습니다. 어쨌든 문자열은 매우 특별합니다. 저는 그들의 행동이 모양이 없기 때문이라고 생각하지 않습니다. 오히려 문자열이 컨테이너보다 스칼라로 더 자주 간주되는 유일한 컬렉션이라는 사실과 관련이 있습니다.

@stevengj 는 broadcast 가 모양이 있는 컨테이너만 지원해야 한다고 생각하는 이유를 개발할 수 있을까요? 튜플도 스칼라로 간주하는 것을 지지하시겠습니까?

broadcast (#16986)에서 튜플을 컨테이너로 취급하는 근거는 실제로는 종종 본질적으로 정적 벡터로 사용되며 broadcast 에서 "스칼라"로 취급하는 것은 어쨌든 매우 유용합니다. 대조적으로 문자열 (a)는 문자열 처리 작업에서 "원자"로 취급되는 경우가 많고 (b) 일반적으로 연속 인덱싱이 없으므로 broadcast 프레임워크에 매우 적합하지 않습니다.

원칙적으로 broadcast 에서 컨테이너로 사용되는 HasShape 반복자를 지원합니다. 위에서 언급했듯이 주요 문제는 HasShape 가 있다고 해서 getindex 작동한다는 보장이 없다는 것입니다.

위에서 언급했듯이 주요 문제는 HasShape가 있다고 해서 getindex가 작동한다는 것을 보장하지 않는다는 것입니다.

#22489와 같은 것이 도움이 될까요? 즉, 반복자가 인덱싱 가능한지 여부를 나타내는 반복자 특성이 있습니까?

#22489와 같은 것이 도움이 될까요? 즉, 반복자가 인덱싱 가능한지 여부를 나타내는 반복자 특성이 있습니까?

그러나 인덱싱 가능한 반복자만 broadcast 됩니까? 모든 iterable(예: keys(::OrderedDict) 의 결과)에 대해 string.(itr, "1") 와 같은 작업을 수행할 수 있는 데 매우 유용하고 이를 구현하기 위해 인덱싱이 필요하지 않기 때문에 너무 제한적으로 들립니다. 0.7/1.0에서 인덱싱을 지원하지 않는 모든 반복자에 대해 오류를 발생시키고 후속 릴리스에서 지원하도록 하는 것이 좋습니다. 어쨌든 반복자를 스칼라로 취급하는 것은 별로 유용하지 않습니다. 그런 다음 1.x 릴리스에서 원하는 모든 동작을 구현할 수 있습니다.

@stevengj 문자열과 튜플에 관한 당신의 주장에 동의하지만, 왜 HasLength 반복자를 튜플로 취급해서는 안 됩니까? 나는 지금까지 이에 대한 근거를 읽지 못했다.

@nalimilan , indexable+hasshape 반복자만 broadcast 지원되어야 한다고 생각하는 경향이 있습니다. 이 함수에 일반 반복자를 집어넣는 것은 그 의미를 너무 많이 혼동합니다. 어느 시점에서는 map 를 사용해야 합니다.

모든 iterable에 대해 string.(itr, "1") 작업을 수행할 수 있다면 매우 유용할 것입니다 ... 어쨌든 iterator를 스칼라로 취급하는 것은 그다지 유용하지 않습니다.

문자열의 경우는 이와 모순됩니다. "1" 인수 자체는 예제에서 반복 가능합니다. 사물의 톤은 반복자입니다 (예 : PyObject PyCall에서의 정의 start 등)에 정렬되지 않은 세트 같은 것들을 포함, broadcast 개념은 정말 나뉩니다.

또한 #24990 은 map 지금보다 훨씬 더 쉽게 만듭니다. 예를 들어 map(string(_,"1"), itr) 있습니다.

@nalimilan , 인덱싱 가능한 + 해시 모양 반복자만 브로드캐스트에서 지원되어야 한다고 생각하는 경향이 있습니다. 일반적인 반복자를 이 함수에 집어넣는 것은 그 의미를 너무 많이 혼동합니다. 어느 시점에서는 map을 사용해야 합니다.

현재 인덱싱 가능한 반복자에 대한 특성이 없습니다. 어떻게 건네주시겠습니까? 내 WIP PR #25356은 인덱싱을 지원하지 않는 반복자에 대해 오류를 발생시킵니다. 반복자를 스칼라로 취급하는 것이 그다지 유용하지 않다고 가정하면 그렇게 나쁘지는 않습니다. 스칼라로 처리하려면 다른 특성이 필요하지 않습니까?

나는 완전히 명확하지 않은 모든 경우에 대해 오류를 발생시키는 경향이 있습니다. 따라서 반드시 그다지 유용하지 않은 기본 동작(예: 일부 반복자를 스칼라로 처리)에 가두기보다는 미래에 모든 동작을 구현할 수 있습니다. . 이 문제에서 알 수 있듯이 broadcast 의 동작은 올바르게 디자인하는 데 시간이 걸립니다.

(FWIW, PyObject 는 IIUC가 Python 반복자를 래핑할지 여부를 미리 알지 못하기 때문에 반복 프로토콜을 구현하기 때문에 나에게 좋은 예처럼 들리지 않습니다. PyObject 는 getfield 오버로딩을 사용하여 표준 Julia 객체처럼 보이게 해야 하는 것처럼 여기에서 분명히 예외입니다. Sets는 좀 더 Julian 예제입니다.)

다른 곳에서 제안된 것처럼 인덱싱 가능한 HasShape 반복자에 대한 특성을 추가할 수 있습니다.

Triage는 브로드캐스트가 모든 인수(예: map)에 대해 반복하도록 하고 연산자 문자를 추가하는 아이디어를 좋아합니다(예: 다른 문제에서 이전에 제안된 대로 const & = Ref 또는 ~ ). 0차원 인수.

@vtjnash , HasShape 가 아닌 반복자에 대해서도 이것이 무엇을 의미합니까? 브로드캐스트가 문자열 및 집합과 같은 항목을 반복하기를 원한다는 뜻입니까? 현재 broadcast 구현은 getindex 와 밀접하게 연결되어 있습니다 ... 특히 다른 차원의 인수를 결합할 때 getindex 없이 구현하는 방법에 대해 생각해 보셨습니까?

이론적으로 인덱싱할 수 없는 반복자(적어도 의미 있는 순서가 있는 반복자)를 지원하는 것이 가능해야 합니다. 모든 입력의 모양이 같으면 쉽습니다. 모양이 다르고 반복자의 모양이 결과와 다르면(작은) 중간 저장소가 필요합니다.

PR https://github.com/JuliaLang/julia/pull/22489 의 IteratorAccess 특성을 조정/재사용하여 인덱싱 가능한 반복자를 감지할 수 있는 것 같습니다. https://github.com/JuliaLang/julia/pull/24774 에서는 어떤 반복자가 인덱싱 가능한지(따라서 keys 구현해야 함) 알고 있어야 합니다 .

참조: @rfourquet

👍 Triage는 이것을 오류로 만들거나(안전한 선택) 수집을 호출(하기 쉬운 경우)할 것을 권장합니다.

선별 심사에서 여기에서 채택할 특정 전략을 결정할 수 있습니까? 예를 들어 위의 @JeffBezanson 의 의견에서 "이것"은 무엇입니까? 인덱싱을 지원하지 않는 모든 반복자에 대해 오류를 발생시켜야 할까요(나중에 원하는 모든 작업을 수행할 수 있도록 현재로서는 가장 안전한 선택), 아니면 일부 반복자를 스칼라로 처리해야 할까요? 인덱싱 가능한 반복자를 위한 특성을 추가해야 합니까? 그렇다면 어떤 형식으로 추가해야 합니까( Base.IteratorSize 대한 새 특성 대 새 선택)? (스칼라와 구별할 수 있도록) 일반적으로 반복자에 대한 특성을 추가해야 합니까?

다음 동작이 좋은 것 같습니다.

• 기본적으로 모든 인수를 반복하고 브로드캐스트하십시오.
• 어떤 이유로 든 작동하지 않으면 오류를 제공하십시오.
• Ref(x) 또는 [x] 를 전달하여 x 를 스칼라로 처리하도록 합니다.
• 새로운 유형이 오류를 제공하는 대신 스칼라로 처리되도록 정의할 수 있는 특성을 추가하십시오. 이것은 반복과 반복하지 않는 것 사이에서 선택하는 데 사용해서는 안 됩니다. 오류를 스칼라 동작으로 바꾸는 것입니다.

마지막 요점에 대한 메모를 명확히 해주실 수 있습니까(예를 들어)? 나는 특성이 존재한다는 것이 무엇을 의미하는지 잘 모르겠지만 반복하거나 반복하지 않는 것 사이에서 선택하는 데 사용되지 않습니다.

따라서 기본적으로 "모든 인수를 반복하고 브로드캐스트하려고"는 모든 비 컬렉션 유형(특히 Number , Symbol 대해 Scalar() 를 반환하도록 BroadcastStyle 를 정의해야 함을 의미합니다 Scalar() Symbol 및 AbstractString )? 그것은 마지막 글머리 기호가 언급한 "특성"처럼 들립니다.

솔직히 말하면, 비인터러블/스칼라에 대한 트레잇을 정의하는 것보다 이터러블에 대한 트레잇을 정의하는 것이 비용이 덜 든다는 것을 알게 될 것입니다. 일부(드문 경우) 경우에 유용할 수 있기 때문에 모든 비 컬렉션 유형이 어느 시점에서 그 Scalar 특성을 구현하지 않을까 걱정됩니다.

마지막 글머리 기호가 언급한 "특성"처럼 들립니다.

아니요, 마지막 글머리 기호는 무언가가 반복을 구현하면 브로드캐스트가 반복한다는 것을 의미합니다. 스칼라 특성이 사라집니다. 분명히 반복할 수 없는 몇 가지 유형(예: Type 및 Function 하위 유형)의 경우 Type 을 변경하는 NotIterable 트레잇을 원할 수 있습니다 MethodError 를 하나의 값(해당 객체)을 생성하는 반복에 넣습니다. 사실 이게 왜 필요했는지 기억이 안난다.

따라서 기본적으로 "모든 인수를 반복하고 브로드캐스트하려고 시도"한다는 것은 모든 비 컬렉션 유형(특히 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 는 계속 작동해야 합니까?

그것이 나에게 일어났지만, 하나의 주장을 특별한 경우로 만드는 것은 혼란스러운 것 같습니다.

다음 비대칭이 보입니다. iterable을 스칼라로 처리하면 정말 이상한 결과가 나오지만 스칼라를 iterable로 처리하면 오류가 발생합니다. 오류가 발생하면 인수를 래핑하여 쉽게 수정할 수 있습니다. 반면 첫 번째 경우에는 인수를 반복하기 위해 수행할 수 있는 간단한 작업이 없습니다.

나는 여전히 브로드캐스트가 HasShape 반복자를 컨테이너로 취급해야 한다고 생각합니다. 이것은 처음부터 방송의 디자인과 일치합니다. 그게 무슨 문제야?

@stevengj IMHO의 잘못된 점은 완벽하게 합리적인 동작이 구현될 수 있을 때 일부 작업이 작동하지 않는다는 것입니다. HasLength 반복자를 Tuple 처럼 처리하십시오. 지금 당장은 지원하지 않더라도 1.x의 어느 시점에서 지원할 수 있는 가능성은 열어두고 싶습니다.

아무도 불평하지 않는다

줄리아> 맵(문자열, [1,2], :a)
오류: MethodError: start(::Symbol)와 일치하는 메서드가 없습니다.

@JeffBezanson OTC, 저는 :a 를 필요에 따라 반복하는 broadcast 의 현재 동작을 지원합니다. 이러한 종류의 것은 예를 들어 일련의 DataFrame 열의 이름을 바꾸는 데 매우 유용할 수 있습니다. map 와 같은 오류가 발생하도록 broadcast 를 변경하시겠습니까?

다음 비대칭이 보입니다. iterable을 스칼라로 처리하면 정말 이상한 결과가 나오지만 스칼라를 iterable로 처리하면 오류가 발생합니다. 오류가 발생하면 인수를 래핑하여 쉽게 수정할 수 있습니다. 반면 첫 번째 경우에는 인수를 반복하기 위해 수행할 수 있는 간단한 작업이 없습니다.

쉽지만 상당히 불편합니다. 스칼라는 오류를 발생시키지 않고 기본적으로 브로드캐스트되어야 한다는 @stevengj의 의견에 동의합니다. 물론 Number 유형이 반복 가능하기 때문에 성가심은 항상 표시되지는 않지만 Symbol 예제에서 알 수 있듯이 일반적으로 별로 도움이 되지 않습니다. Char 이 고생합니다 패키지에 정의 된 다른 많은 사용자 정의 형식이 될 것이다 (그리고 정의 결국 자신의 BroadcastStyle 로 Scalar() ).

문제의 핵심은 컬렉션과 스칼라를 구별하는 특성이 없다는 것입니다. 따라서 가장 직접적인 해결책은 실제로 HasShape 반복자를 컬렉션으로 처리하고 다른 유형을 스칼라로 처리하는 것입니다(모든 유형의 기본값이므로 HasLength 반복자를 포함). 개인적으로 나는 컬렉션/이터러블에 대한 특성을 도입하는 것이 많은 의미가 있다고 생각하지만, 우리가 그렇게 할 준비가 되지 않았고 이터러블을 감지하기 위해 정의된 start 에 의존할 수 없다면 저는 현재의 행동을 유지해야 할까봐 두렵습니다.

https://github.com/JuliaLang/julia/issues/18618#issuecomment -360594955에 있는 Jeff의 제안에는 Symbol 및 Char 를 "스칼라" 유형으로 취급하는 브로드캐스트를 허용할 여지가 있습니다. 행동에 동의해야 합니다. start 구현하지 않기 때문에 기본적으로 오류가 됩니다.

여기서 가장 설득력 있는 부분은 "컬렉션" 유형에 대한 유일한 합리적인 정의는 반복 가능하다는 것입니다. 예, 문자열이 컬렉션임을 의미합니다. 때때로 그들은 그렇게 사용됩니다! 따라서 사람들이 호출 사이트에서 다른 사람에게 쉽게 옵트인할 수 있도록 하는 동작을 기본으로 설정해 보겠습니다.

하지만 여기에 사마귀가 있습니다. 숫자는 반복 가능하므로( HasShape ) 0차원 컨테이너로 취급됩니다. 즉, 논리적 결론에 따르면 1 .+ 2 != 3 입니다. 대신 fill(3, ()) 입니다.

편집: 스레드가 더 이상 탈선하지 않도록 하기 위해 담론으로 이동:

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

#18618(comment)에 있는 Jeff의 제안에는 Symbol 및 Char를 "스칼라" 유형으로 취급하는 브로드캐스트를 허용할 여지가 있습니다. 기본적으로 시작을 구현하지 않기 때문에 오류가 됩니다.

네, 제 입장은 스칼라가 더 자연스러운 폴백이라는 가정에 기반을 두고 있습니다. 특히 컬렉션은 일부 메서드(반복, 인덱싱)를 구현해야 하는 반면 스칼라는 "나머지"이고 공통점이 없다는 점을 감안할 때 더욱 그렇습니다. 결국 모든 유형은 원하는 모든 동작을 구현할 수 있지만 가능한 한 편리하고 논리적으로 만들어야 합니다. 이는 특히 불일치를 피하는 데 도움이 됩니다(예: 일부 유형은 선언되고 스칼라로 작동하고 다른 유형은 그렇지 않음).

다른 유형에 대한 규칙이 명확하다면 문자열 및 숫자와 같은 필수 유형에 대한 몇 가지 예외가 있는 것에 대해 지나치게 걱정하지 않습니다.

저는 우리의 반복 및 인덱싱 인터페이스에 대해 조금 생각했습니다. 나는 우리가 반복하는(하지만 인덱싱할 수는 없는) 유용한 객체, 인덱싱될 수 있는(그러나 반복할 수 없는) 객체, 그리고 둘 다 수행하는 객체를 가질 수 있다는 점에 주목합니다. 이를 바탕으로 다음 사항이 궁금합니다.

• map 강하게 반복 프로토콜에 묶여 수 있습니다 - 우리가 게으른 할 수있는 유효한 것 out = map(f, iterable) 에 대한 임의의 iterable 예는 그런를 first(out) 는 IS f(first(iterable)) 와 같으며 이 일반적인 게으른 작업이 유용할 수 있을 것 같습니다.
• broadcast 는 인덱싱 인터페이스에 강력하게 연결될 수 있습니다. out[i] 가 f(indexable[i]) 와 같도록 게으른 out = broadcast(f, indexable) 만들 수 있는 것이 타당해 보입니다. 이 일반적인 게으른 작업이 유용할 수 있을 것 같습니다. 분명히 여러 입력이 있는 broadcast 는 여전히 현재 하는 모든 멋진 일을 할 수 있습니다. 브로드캐스팅을 위해 스칼라는 인덱싱할 수 없는 것입니다(또는 Number 및 Ref 및 AbstractArray{0} 와 같이 사소한 인덱싱).

또한 단일 인수 map 및 단일 인수 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. 브로드캐스트 방법을 설명하는 몇 가지 방법을 구현하려면 _everything_이 필요합니다.
2. 사물을 컨테이너로 처리하고 컨테이너가 아닌 경우 오류/사용 중단을 기본으로 합니다.
   
   
   
   • 알 수 없는 개체를 iterate 하려고 하면 스칼라에 대해 오류가 발생합니다.
   
   
   • 스칼라에는 두 가지 탈출구가 있습니다. 사용자는 호출 사이트에서 래핑할 수 있고 도서관 작성자는 래핑되지 않은 스칼라형 브로드캐스팅을 선택할 수 있습니다.
   
   
3. 알 수 없는 컨테이너에 대한 스칼라 및 오류로 처리하는 것이 기본값입니다.
   
   
   
   • 스칼라에 대해서만 정의된 관련 메서드가 없다는 점을 감안할 때 iterate 에서 메서드 오류가 발생한다고 주장해야 합니다. 느리고 순환적입니다.
   
   
   • 오류가 발생하지 않도록 사용자 정의 컨테이너에 사용할 수 있는 탈출 해치는 단 하나뿐입니다. 라이브러리 작성자는 명시적으로 브로드캐스트를 선택합니다. 이것은 컨테이너 작업이 주 목적인 함수의 경우 상당히 거꾸로 보입니다.
   
   
4. applicable(iterate, …) 하고 그에 따라 동작을 전환합니다.
   
   
   
   • 이것은 현재 start/next/done의 지원 중단 메커니즘으로 인해 작동하지 않으며 일반적으로 메서드를 멤버에게 연기하는 래퍼 유형에 대해 잘못될 수 있습니다.
   
   

옵션 1은 모든 사람에게 더 나쁘고, 옵션 2는 현재 상태이며, 옵션 3은 역방향이며, 옵션 4는 이전에 한 번도 해본 적이 없고 버그가 있을 가능성이 있는 것입니다.

일부 토론은 배후에서 발생했음에 틀림없다고 생각하지만 이 스레드와 https://github.com/JuliaLang/julia/pull/25356 에서 nalimilan 에 대해 본 주장에 대해서는 확신이 서지 않습니다 stevengj 의 위치.

오류가 발생하지 않도록 사용자 정의 컨테이너에 사용할 수 있는 탈출 해치는 단 하나뿐입니다. 라이브러리 작성자는 명시적으로 브로드캐스트를 선택합니다. 이것은 컨테이너 작업이 주 목적인 함수의 경우 상당히 거꾸로 보입니다.

이것이 저의 주된 의견 불일치입니다. 나에게 모든 Julia 코드에서 # of iterator types << # of types that should be treated as scalars in a broadcast situation < # of broadcast calls . 따라서 '추가' 작업을 수행해야 하는 횟수가 브로드캐스트 호출 수보다 반복자 유형 수에 따라 조정되는 경우 선호합니다. 그리고 만약 라이브러리 작성자가 반복자를 정의한다면, 그들에게 하나 이상의 메소드를 정의하도록 요구하는 것이 완전히 불합리한 것은 아니지만, 모든 패키지 작성자에게 반복 불가능한 모든 유형에 대해 Base.broadcastable(x) = Ref(x) 를 정의하도록 요구하는 것은 _완전히 불합리합니다. broadcast 호출의 높은 비율에서 못생긴 (IMHO) Ref broadcast 를 피하십시오.

반복을 정의하기 위해 단일 메서드를 구현하는 것이 좋다는 것을 알고 있지만 새 특성에 대해 하나 더 구현하거나 새 반복자에 대해 Base.iteratorsize 를 지정해야 하도록 만드는 것은 그리 많은 작업이 아닙니다. 문제가 있는 HasLength 기본값 제거). 그러면 broadcastable 대체 방법이 해당 특성을 기반으로 할 수 있습니다. 또는 단일 메서드로 반복을 정의하는 것을 정말 좋아한다면 https://github.com/JuliaLang/ 에서와 같이 명시적 특성 기본값을 applicable(iterate, ...) 로 설정할 수 있습니다. 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 위에 주어진 주장은 완전히 설득력이 없을 수 있습니다. 다음은 보다 완전한 두 가지 질문입니다.

1) broadcastable 를 모든 iterable에 대한 필수 인터페이스로 만드는 것이 가능합니다.
이것은 완전히 체계적이며 개발자가
이터레이터가 브로드캐스트에서 어떻게 동작해야 하는지.
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 실제로