+1

또는 func.(args...) 에 대한 구문 설탕으로

broadcast(func, args...)

하지만 저만 그렇게 선호할까요?
어느 쪽이든, +1.

:-1: f[...] 에 대한 Stefan의 다른 제안 은 이해와 매우 유사하다고 생각합니다.

@ihnorton 처럼 저도 이 아이디어를 별로 좋아하지 않습니다. 특히 a .+ b 와 sin.(a) 가 모두 있는 비대칭이 싫습니다.

특별한 구문이 필요하지 않을 수도 있습니다. #1470을 사용하면 다음과 같은 작업을 수행할 수 있습니다.

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

오른쪽? 어떤 기능에서든 자동 매핑을 사용하기에는 너무 마술적일 수 있습니다.

@quinnj 그 한 줄은 호출 과부하 허용에 대한 나의 가장 큰 두려움을 요약합니다. 나는 며칠 동안 잠을 잘 수 없습니다.

구문상 가능한지 아직 확실하지 않지만 .sin(x) 는 어떻습니까? a .+ b 와 더 비슷합니까?

[] 이(가) 너무 과부하되어 이 용도로 작동하지 않을 것 같습니다. 예를 들어, Int(x) 을 쓸 수 있지만 Int[x] 는 배열을 구성하므로 map 를 의미할 수 없습니다.

.sin(x) 로 탑승합니다.

이를 위해 일부 구문을 회수해야 하지만 Int(x) 가 스칼라 버전이면 Int[x] 는 유추에 따라 Int 요소 유형의 벡터를 구성하는 것이 합리적입니다. 내 생각에 그 구문을 보다 일관성 있게 만들 수 있는 기회는 실제로 f[v] 제안의 가장 매력적인 측면 중 하나입니다.

map f[v] 구문을 만드는 것이 구문을 더 일관성 있게 만드는 방법은 무엇입니까? 이해가 안 돼요. map 는 현재 T[...] 배열 생성자 구문과 "모양"이 다릅니다. Vector{Int}[...] 는 어떻습니까? 작동하지 않겠습니까?

lol, @JeffBezanson을 놀라게 해서 죄송합니다! 하하, 호출 오버로딩은 확실히 약간 무섭습니다. 가끔 julia에서 할 수 있는 코드 난독화의 종류에 대해 생각하고 call 를 사용하여 약간의 거친 작업을 수행할 수 있습니다.

.sin(x) 도 좋은 아이디어라고 생각합니다. 다중 인수로 무엇을 할 것인지에 대한 합의가 있었습니까?

:-1:. 고차 함수를 사용하는 것과 비교하여 몇 개의 문자를 저장하는 것은 가독성 측면에서 비용 가치가 있다고 생각하지 않습니다. .func() / func.() 및 func() 가 도처에 산재된 파일을 상상할 수 있습니까?

어쨌든 적어도 a.(b) 구문은 제거할 것 같습니다.

와우, 꿀벌 둥지를 휘젓는 것에 대해 이야기하십시오! 토론을 더 잘 반영하기 위해 이름을 변경했습니다.

2-인수 map 의 이름을 zipWith 로 변경할 수도 있습니다. :)

일부 구문이 정말로 필요한 경우 [f <- b] 또는 대괄호 _inside_ 이해에 대한 다른 말장난은 어떻습니까?

( @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/jakeboewski/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 를 선호하는 또 다른 이유는 Base.(+) 를 사용하여 + Base (한 번 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 가 많은 도움이 될 것이라고 생각하지 않습니다. ;)

IIRC, Haskell에서 위의 filter ((==val) . func2 . fst) $ map (func1 other args) container 는 func1 인수 순서를 약간 변경하여 작성할 수 있습니다.

elm에서 .func 는 x->x.func 로 정의되며 이것은 매우 유용합니다. elm records 를 참조하십시오. map 에 대해 이 구문을 사용하기 전에 이를 고려해야 합니다.

나는 그것을 좋아한다.

Julia에서는 많은 언어에서와 같이 현장 액세스가 그다지 중요하지 않습니다.

예, Julia의 필드가 "개인"용으로 더 많이 사용되기 때문에 여기서는 덜 관련성이 있습니다. 그러나 필드 액세스 오버로드에 대한 지속적인 논의로 인해 더 합리적일 수 있습니다.

$#$ .+ 와 비대칭이 아닌 경우 f.(x) 은 덜 문제가 있는 솔루션처럼 보입니다. 그러나 . 의 상징적 연관을 "요소별 작업"에 유지하는 것은 좋은 생각입니다.

현재 형식화된 배열 구성이 더 이상 사용되지 않을 수 있는 경우 func[v...] 를 map(func, v...) 로 변환할 수 있으며, 그러면 리터럴 배열을 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 $를 생성합니까?

아니요. 내가 말했듯이 두 개의 서로 다른 호출 교환원이 있어야 한다는 의미는 전혀 아닙니다. 요소별 작업에 대해 _시각적으로_ 일관된 구문을 찾으려고 합니다.

나에게 이러한 옵션을 없애는 것은 다중 인수 함수를 벡터화하는 방법에 대한 질문입니다. 그것을 할 수 있는 단일한 방법은 없으며 가능한 모든 방법을 지원하기에 충분히 일반적인 것은 우리가 이미 가지고 있는 다차원 배열 이해와 매우 유사해 보이기 시작합니다.

다중 인수 map 가 모든 인수를 반복하는 것은 표준입니다.
만약 우리가 이것을 했다면 나는 .( 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에서 오는 사람들에게 큰 성가심일 것입니다(적어도 다른 언어에 대해서는 잘 모릅니다). 그리고 Julia가 데이터 분석에 적합하지 않다는 느낌을 주기 위해 이것이 마음에 들지 않습니다.

또 다른 문제는 일관성입니다. log , exp 등을 포함하여 현재 벡터화된 모든 기능을 기꺼이 제거하고 사람들에게 map 대신 map를 사용하도록 요청하지 않는 한 이 결정의 실용성에 대한 흥미로운 테스트), 언어가 일관성이 없어 함수가 벡터화되었는지 여부(그리고 어떤 인수에 대해)를 미리 알기가 어렵습니다.

많은 다른 언어들이 몇 년 동안 map 를 사용해 왔습니다.

모든 것을 벡터화하는 것을 중단하려는 계획을 이해하면서 대부분의/모든 벡터화된 기능을 제거하는 것이 항상 전략의 일부였습니다.

예, _물론_ 우리는 모든 것을 벡터화하는 것을 중단할 것입니다. 불일치가 이미 존재합니다. 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 의 예가 꽤 말하고 있다고 생각합니다. 벡터화된 구문은 다른 솔루션보다 훨씬 더 훌륭하고 수학 공식에 훨씬 더 가깝습니다. 나는 그것을 잃는 것이 매우 나쁠 것이고 다른 과학 언어에서 오는 사람들은 아마도 이것을 Julia에서 부정적인 점으로 생각할 것입니다.

나는 모든 벡터화된 함수( map 가 충분히 빠를 때)를 제거하는 데 문제가 없으며 어떻게 진행되는지 확인합니다. 저는 편리한 구문을 제공하는 것에 대한 관심이 그 시점에서 훨씬 더 가시적일 것이라고 믿으며, 사실이 밝혀지면 여전히 추가해야 할 때입니다.

Julia는 대화형 사용(이 경우 긴 표현식은 입력하기 귀찮음)과 수학적 계산(코드를 읽을 수 있도록 수식은 가능한 한 수학 표현식에 가까워야 함)을 강조하기 때문에 Julia가 다른 많은 언어와 다르다고 생각합니다. 이것이 부분적으로 Matlab, R 및 Numpy가 벡터화된 기능을 제공하는 이유입니다(다른 이유는 물론 성능이며 Julia에서는 사라질 수 있는 문제입니다).

토론에서 내 느낌은 벡터화된 수학의 중요성이 과소평가되었다는 것입니다. 사실, 벡터화된 수학의 주요 장점 중 하나는 표현의 간결함에 있습니다. "for-loop이 느린 언어"에 대한 임시방편 이상의 의미가 있습니다.

y = exp(x) 와 비교

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

전자는 분명히 후자보다 훨씬 더 간결하고 읽기 쉽습니다. Julia가 루프를 효율적으로 만든다는 사실이 우리가 항상 코드를 역벡터화해야 한다는 것을 의미하지는 않습니다. 이것은 제게는 상당히 역효과입니다.

우리는 사람들이 자연스럽게 코드를 작성하도록 장려해야 합니다. 한편으로, 이것은 우리가 적합하지 않은 컨텍스트에서 복잡한 코드를 작성하고 벡터화된 함수를 비틀어서는 안 된다는 것을 의미합니다. 반면에 벡터화된 수학이 가장 합리적일 때마다 사용을 지원해야 합니다.

실제로 수식을 숫자 배열에 매핑하는 것은 매우 일반적인 작업이므로 번거롭지 않게 하기 위해 노력해야 합니다. 이를 위해 벡터화된 코드는 가장 자연스럽고 간결한 방식으로 유지됩니다. 성능은 제쳐두고, 특히 다중 인수가 있는 복합 표현식의 경우 map 함수를 호출하는 것보다 여전히 낫습니다.

우리는 확실히 모든 것의 벡터화된 버전을 원하지 않지만, 벡터화하기 위해 매번 맵을 사용하는 것은 위에서 언급한 Dahua 때문에 짜증날 것입니다.

맵이 빨랐다면 확실히 더 작고 의미 있는 벡터화된 함수 세트에 집중할 수 있었을 것입니다.

나는 간결한 지도 표기법을 지지하는 측면에서 강하게 내려온다고 말해야 한다. 나는 그것이 서로 다른 요구들 사이의 최상의 타협이라고 생각합니다.

나는 벡터화된 함수를 좋아하지 않는다. 무슨 일이 일어나고 있는지 숨깁니다. 함수의 벡터화된 버전을 만드는 이러한 습관은 미스터리 코드로 이어집니다. 패키지의 f 함수가 벡터에서 호출되는 코드가 있다고 가정해 보겠습니다. 함수가 무엇을 하는지에 대한 아이디어가 있더라도 요소별로 수행하는지 또는 벡터 전체에서 작동하는지 여부를 코드를 읽으면 확신할 수 없습니다. 과학 컴퓨팅 언어가 이러한 벡터화된 기능을 가진 이력이 없었다면 지금처럼 거의 수용하지 않았을 것입니다.

또한 함수가 사용되는 간결한 코드를 가능하게 하기 위해 벡터화된 버전의 함수를 작성하도록 암시적으로 권장되는 상황으로 이어집니다.

진행 중인 작업에 대해 가장 명시적인 코드는 루프이지만 @lindahua 가 말했듯이 매우 장황해지며 특히 대화식 사용을 의미하는 언어에서 자체 단점이 있습니다.

이것은 map 절충안으로 이어지며 이상적이라고 생각하지만 충분히 간결하지 않다는 @lindahua 의 의견에는 여전히 동의합니다.

@lindahua 에 동의하지 않는 부분은 앞서 언급한 이유로 벡터화된 함수가 최선의 선택이라는 것입니다. 내 추론으로 이어지는 것은 Julia가 map 에 대해 매우 간결한 표기법을 가져야 한다는 것입니다.

Mathematica가 약식 표기법을 사용하는 방법이 정말 매력적이라는 것을 알았습니다. Mathematica에서 인수에 함수를 적용하기 위한 약식 표기법은 @ 이므로 Apply 함수를 벡터에 f 로 지정하면 f @ vector 입니다. . 함수 매핑에 대한 관련 약식 표기법은 /@ 이므로 f 를 f /@ vector 와 같이 벡터에 매핑합니다. 여기에는 몇 가지 매력적인 특성이 있습니다. 두 단축형은 모두 간결합니다. 둘 다 @ 기호를 사용한다는 사실은 그들이 하는 일 사이에 관계가 있음을 강조하지만 지도의 / 는 매핑할 때와 언제 매핑할 때 명확하게 하기 위해 여전히 시각적으로 구별됩니다. 아니다. 이것은 Julia가 Mathematica의 표기법을 맹목적으로 복사해야 한다는 것을 말하는 것이 아니라 매핑에 대한 좋은 표기법이 매우 가치 있다는 것뿐입니다.

나는 모든 벡터화된 함수를 제거하는 것을 제안하지 않습니다. 그 기차는 역을 떠난 지 오래입니다. 오히려 벡터화된 함수 목록을 가능한 한 짧게 유지하고 벡터화된 함수 목록에 추가하지 않도록 간결한 맵 표기법을 제공하는 것이 좋습니다.

물론 이 모든 것은 map 및 익명 함수가 빠를 때 조건부입니다. 지금 Julia는 이상한 위치에 있습니다. 루프가 느리기 때문에 함수가 벡터화된 과학 컴퓨팅 언어의 경우였습니다. 이것은 문제가 되지 않습니다. 대신 Julia에서는 맵 및 익명 함수가 느리기 때문에 함수를 벡터화했습니다. 그래서 우리는 우리가 시작한 곳으로 돌아갔지만 다른 이유가 있습니다.

벡터화된 라이브러리 함수에는 한 가지 단점이 있습니다. 라이브러리에서 명시적으로 제공하는 함수만 사용할 수 있습니다. 즉, 예를 들어 sin(x) 는 벡터에 적용할 때 빠르지 sin(2*x) 는 두 번 순회해야 하는 중간 배열이 필요하기 때문에 갑자기 훨씬 느립니다(먼저 쓰기, 다음 읽기).

한 가지 솔루션은 vectorizABLE 수학 함수의 라이브러리입니다. 인라인을 위해 LLVM에서 사용할 수 있는 sin , cos 등의 구현입니다. 그런 다음 LLVM은 이 루프를 벡터화하여 매우 효율적인 코드로 이어질 수 있습니다. Yeppp는 올바른 루프 커널을 가지고 있는 것 같지만 인라인을 위해 노출하지 않는 것 같습니다.

패러다임으로서의 벡터화의 또 다른 문제는 표준 라이브러리에 의해 축복받은 다른 컨테이너 유형을 사용하는 경우에는 전혀 작동하지 않는다는 것입니다. DataArrays에서 이것을 볼 수 있습니다. 우리가 정의하는 새로운 컨테이너 유형에 대한 함수를 다시 벡터화하는 데 사용되는 엄청난 양의 메타프로그래밍 코드가 있습니다.

그것을 @eschnett 의 요점과 결합하면 다음을 얻습니다.

• 벡터화된 함수는 표준 라이브러리의 함수로 제한하는 경우에만 작동합니다.
• 벡터화된 함수는 표준 라이브러리의 컨테이너 유형으로 제한하는 경우에만 작동합니다.

내 요점은 벡터화된 함수를 항상 유지해야 한다는 것이 아니라 벡터화된 함수를 작성하는 것만큼 간결한 방법이 필요하다는 것입니다. map 를 사용하는 것은 아마도 이것을 만족시키지 못할 것입니다.

일부 함수에 _vectorizable_ 태그를 지정하는 @eschnett 의 아이디어가 마음에 듭니다. 컴파일러는 사용자가 벡터화된 버전을 명시적으로 정의하지 않고도 벡터화 가능한 함수를 배열에 자동으로 매핑할 수 있습니다. 컴파일러는 벡터화 가능한 함수 체인을 융합 루프로 융합할 수도 있습니다.

@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_으로 선언하는 것은 바람직하지 않다고 생각합니다.

$#$5 $#4$#$의 pure 및 associative 태그에서 + sum 의 $# reduce vec 속성을 다시 파생시킬 수 없습니다. reduce / foldl / foldr 는 pure 및 associative 함수가 주어졌을 때 작동합니까? 분명히 이것은 모두 가상의 것이지만 Julia가 유형에 대한 특성에 모두 참여했다면 함수에 대한 특성에도 모두 참여하여 벡터화에 대한 최신 기술을 상당히 개선하는 것을 상상할 수 있었습니다.

새 구문을 추가하는 것은 우리가 원하는 것과 반대되는 것 같습니다(Any[] 및 Dict에 대한 특수 구문을 정리한 후). 이러한 벡터화된 함수를 제거하는 전체 _point_는 특별한 경우를 줄이기 위한 것입니다(그리고 저는 구문이 함수 의미론과 달라야 한다고 생각하지 않습니다). 그러나 간결한 지도가 유용할 것이라는 데 동의합니다.

그렇다면 왜 간단한 중위어 map 연산자를 추가하지 않습니까? 여기서 임의로 $ 선택하겠습니다. 이것은 @lindahua 의 예시를 다음과 같이 만들 것입니다.

exp(0.5 * abs2(x - y))

에게

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

이제 사용자 정의 중위 연산자에 대한 Haskell과 같은 지원만 있다면 ($) = map 한 줄만 변경됩니다. :)

IMO, 다른 구문 제안은 시각적으로 기존 구문에 너무 가깝고 코드를 볼 때 구문 분석하는 데 정신적 노력이 더 필요합니다.

• foo.(x) -- 표준 유형 멤버 액세스와 시각적으로 유사합니다.
• foo[x] -- foo 배열의 x번째 멤버에 액세스하고 있습니까 아니면 여기에서 맵을 호출합니까?
• .foo(x) -- @kmsquire 가 지적한 대로 문제가 있습니다.

그리고 @vec 솔루션이 처음부터 피하려는 @vectorize 에 너무 가깝다고 생각합니다. 확실히, 일부 주석 ala #8297은 있으면 좋을 것이며 미래에 도움이 될 수 있습니다. 그러면 더 똑똑한 컴파일러가 이러한 스트림 융합 기회를 인식하고 그에 따라 최적화할 수 있습니다. 그러나 나는 그것을 강요하는 생각을 좋아하지 않습니다.

Infix 맵과 빠른 익명 기능은 다음과 같은 작업을 허용하는 경우 임시 생성에 도움이 될 수 있습니다.

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

벡터화할 수 있는 기능을 지정하는 맥락에서 멋진 새로운 Trait.jl 의 아이디어를 빌릴 수 있는지 궁금합니다. 물론 이 경우 우리는 특정 특성을 가진 julia Type 대신 Function 유형의 개별 _instances_가 벡터화 가능 여부를 보고 있습니다.

이제 사용자 정의 중위 연산자에 대한 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에서 이것을 구현할 수 있기 때문에 상황이 더 쉬울 것입니다(매크로 대 템플릿).

고려해야 할 또 다른 사항이 있습니다. IEEE 표준의 일부를 포기하면 속도를 크게 향상시킬 수 있습니다. 많은 사용자는 예를 들어 비정규화된 숫자가 중요하지 않거나 입력이 항상 sqrt(max(Double)) 보다 작다는 것을 알고 있습니다. 문제는 이러한 경우에 빠른 경로를 제공할지 여부입니다. 나는 이것에 매우 관심이 많다는 것을 알고 있지만, 다른 사람들은 그 대신 정확히 재현 가능한 결과를 선호할 수도 있습니다.

Julia에서 벡터화 가능한 exp 프로토타입을 만들어 보겠습니다. 그런 다음 루프를 벡터화할 때 LLVM이 수행하는 작업과 얻을 수 있는 속도를 확인할 수 있습니다.

함수의 인수에 전각 괄호를 사용하는 것이 너무 무섭습니까~

죄송합니다. @johnmyleswhite 가 위에서 트레잇을 사용하여 기능에 대해 말한 것과 똑같은 것을 반복하고 있다는 것을 깨닫지 못했습니다. 계속하십시오.

@eschnett API(함수가 벡터화할 수 있는지 여부)를 구현 세부 정보(함수가 컴파일되는 방법)에 연결하는 것이 합리적이지 않다고 생각합니다. 시간과 아키텍처 전반에 걸쳐 이해하고 안정적으로 유지하는 것은 매우 복잡하게 들리며 외부 라이브러리에서 함수를 호출할 때는 작동하지 않습니다. 예를 들어 log 는 openlibm에서 함수를 호출하기 때문에 벡터화 가능한 것으로 감지되지 않습니다.

OTOH @johnmyleswhite 의 특성을 사용하여 함수의 수학적 속성이 무엇인지 전달하는 아이디어는 훌륭한 솔루션이 될 수 있습니다. ( @lindahua 님 의 제안은 제가 조금 전에 어디선가 제안한 기능이지만, 특성을 사용하는 솔루션이 더 나을 수도 있습니다.)

이제 사용자 정의 중위 연산자에 대한 Haskell과 같은 지원만 있다면

6582 #6929 충분하지 않습니까?

나는 다음과 같이 말했어야 했다: ... 사용자 정의 _비유니코드_ 중위 연산자, 사용자가 이러한 핵심 기능에 액세스하기 위해 유니코드 문자를 입력하도록 요구하고 싶지 않기 때문입니다. $ 가 실제로 추가된 것 중 하나인 것을 보았지만 감사합니다! 와우, 그래서 이것은 Julia _today_에서 실제로 작동합니다(비록 "빠르지는" 않지만... 아직):

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

map 에 대한 최선의 선택인지는 모르겠지만 xor $ 를 사용하는 것은 정말 낭비인 것 같습니다. Bitwise xor는 그렇게 자주 사용되지 않습니다. map 가 훨씬 더 중요합니다.

위의 @jiahao 의 요점은 매우 좋은 점입니다. exp 와 같은 개별 벡터화된 함수는 실제로 exp(-x^2) 와 같은 벡터화된 _표현식_을 얻기 위한 일종의 해킹입니다. @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 핑의 모양을 나타내므로 다차원 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 매크로가 있습니까?

-에릭

2014년 11월 2일 일요일 오후 8시 26분에 Tim Holy [email protected] 은 다음과 같이 썼습니다.

나는 이것이 함수의 속성이 아니라는 데 동의합니다.
기능의 사용. 특성 적용에 대한 논의는 다음과 같습니다.
잘못된 나무를 짖는 경우.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8450#issuecomment -61433026.

에릭 슈 네터 [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

exp 와 같은 개별 벡터화된 함수는 실제로 exp(-x^2) 와 같은 벡터화된 _표현식_을 얻기 위한 일종의 해킹입니다.

스칼라 영역에서 전체 표현식을 들어올리기 위한 핵심 구문은 매우 흥미로울 것입니다. 벡터화는 한 가지 예에 불과합니다(대상 도메인이 벡터인 경우). 또 다른 흥미로운 사용 사례는 의미 체계가 상당히 다른 매트릭스 도메인(#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가 더 나을 것입니다.)

Re: unrolling, @toivoh 의 julia-users 게시물 도 참조하세요. #6271을 시도해 볼 가치가 있습니다.

@nalimilan 나는 아직 이것을 생각하지 않았지만 스칼라->행렬 리프팅은 단일 matrixfunc 함수(말하자면)로 구현하는 것이 매우 간단할 것입니다. 하나의 가상 구문(완전히 무언가를 구성하는)은 다음과 같습니다.

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

그러면

1. X 유형이 Matrix{Float64} 이고 요소(유형 매개변수) Float64 가 있는 X 에서 상승도의 소스 및 대상 도메인 식별(따라서 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) 가 될 수 있습니다. 전화 map(x->exp(c*x^2)*sin(x), X) .

소스 및 대상 도메인을 명시적으로 지정하는 다른 방법(예: lift(Number=>Matrix, x->exp(c*x^2)*sin(x), X) )도 상상할 수 있습니다.

@nalimilan 벡터화는 실제로 API의 속성이 아닙니다. 오늘날의 컴파일러 기술을 사용하면 함수가 인라인인 경우에만 벡터화할 수 있습니다. 상황은 대부분 함수 구현에 따라 달라집니다. "올바른 방법"으로 작성되면 컴파일러에서 이를 벡터화할 수 있습니다(주변 루프에 인라인한 후).

@eschnett : 다른 분들과 같은 벡터화 의미를 사용하고 계신가요? @nalimilan 이 의미하는 바를 이해하지 못하는 SIMD 등에 관한 것 같습니다.

오른쪽. 벡터화에는 두 가지 다른 개념이 있습니다. 하나의 거래
긴밀한 내부 루프(프로세서 벡터화)를 위해 SIMD를 얻습니다. 메인
여기에서 논의되는 문제는 어떻게 든 "자동으로"의 구문/의미입니다.
컬렉션에서 단일(또는 다중) 인수 함수를 호출할 수 있습니다.

2014년 11월 4일 화요일 오후 7시 44분, John Myles White 알림 @github.com
썼다:

@eschnett https://github.com/eschnett : 같은 의미를 사용하고 있습니까?
다른 사람들과 같은 벡터화? SIMD 등에 관한 것 같습니다.
@nalimilan https://github.com/nalimilan 을 이해하는 것이 아닙니다.
평균.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8450#issuecomment -61738237.

다른 . 연산자와 대칭으로 f.(x) 함수 모음을 값 모음에 적용하지 않아야 합니까? (예를 들어, 일부 단위 좌표계에서 물리적 좌표로 변환하는 경우.)

구문을 논의하는 동안 명시적 루프를 사용하여 map(log, x) 에 해당하는 것을 표현하는 것이 너무 느리다는 생각이 떠올랐습니다. 따라서 이것을 충분히 빠르게 만들 수 있다면 map 를 호출하거나(또는 특수 구문을 사용하여) 루프를 작성하는 것이 의미 수준에서 동일하며 구문 명확성을 도입할 필요가 없습니다. 현재 벡터 로그 함수를 호출하는 것이 배열에 루프를 작성하는 것보다 훨씬 빠르기 때문에 사람들이 코드에서 이러한 구분을 표현할 방법을 묻게 됩니다.

여기에는 (1) 구문 및 의미 체계, (2) 구현이라는 두 가지 수준의 문제가 있습니다.

구문 및 의미 문제는 사용자가 주어진 배열에 요소별/브로드캐스팅 방식으로 특정 계산을 매핑하려는 의도를 표현하는 방법에 관한 것입니다. 현재 Julia는 벡터화된 함수를 사용하고 사용자가 루프를 명시적으로 작성할 수 있도록 하는 두 가지 방법을 지원합니다(때로는 매크로의 도움으로). 어느 쪽도 이상적이지 않습니다. 벡터화된 함수를 사용하면 exp(0.5 * (x - y).^2) 와 같은 매우 간결한 표현식을 작성할 수 있지만 두 가지 문제가 있습니다. 개발자 측의 끝없는 논쟁과 사용자 측의 혼란(특정 기능이 벡터화되었는지 여부를 파악하기 위해 종종 문서를 검색해야 함). (2) 기능 경계를 넘어 루프를 융합하기 어렵게 만듭니다. 이 시점에서 그리고 아마도 앞으로 몇 개월/몇 년이 지나면 컴파일러는 여러 기능을 함께 살펴보고, 공동 데이터 흐름을 식별하고, 기능 경계를 넘어 최적화된 코드 경로를 생성하는 것과 같은 복잡한 작업을 수행할 수 없을 것입니다.

map 함수를 사용하면 여기서 문제 (1)을 해결할 수 있습니다. 그러나 이것은 여전히 ​​문제를 해결하는 데 도움이 되지 않습니다. (2) -- 특정 벡터화된 함수 또는 일반 map 함수를 사용하면 항상 루프 융합을 방해하는 함수 경계가 생성됩니다. 고성능 계산에 중요합니다. map 함수를 사용하면 또한 장황하게 됩니다. 예를 들어 위의 표현식은 이제 map(exp, 0.5 * map(abs2, x - y)) 와 같이 더 긴 문장이 됩니다. 이 문제가 더 복잡한 표현으로 악화될 것이라고 합리적으로 상상할 수 있습니다.

이 스레드에 요약된 모든 제안 중에서 저는 개인적으로 매핑을 표시하기 위해 특수 표기법을 사용하는 것이 앞으로 가장 유망한 방법이라고 생각합니다. 첫째, 표현의 간결함을 유지한다. 예를 들어 $ 표기법을 사용하면 위의 표현식을 이제 exp $(0.5 * abs2$(x - y)) 로 작성할 수 있습니다. 이것은 원래의 벡터화된 표현식보다 약간 더 길지만 그렇게 나쁘지는 않습니다. 매핑의 각 호출에 $ 를 삽입하기만 하면 됩니다. 다른 한편으로, 이 표기법은 컴파일러가 함수 경계를 깨고 융합 루프를 생성하는 데 사용할 수 있는 수행 중인 매핑의 명확한 표시기 역할을 합니다. 이 과정에서 컴파일러는 함수의 내부 구현을 볼 필요가 없습니다. 컴파일러가 알아야 할 것은 함수가 주어진 배열의 각 요소에 매핑된다는 것뿐입니다.

최신 CPU의 모든 기능, 특히 SIMD의 기능을 감안할 때 여러 루프를 하나로 통합하는 것은 고성능 계산을 향한 한 단계일 뿐입니다. 이 단계 자체는 SIMD 명령어의 활용을 트리거하지 않습니다. 좋은 소식은 이제 @simd 매크로가 있다는 것입니다. 컴파일러는 그렇게 하는 것이 안전하고 유익하다고 생각할 때 생성된 루프의 시작 부분에 이 매크로를 삽입할 수 있습니다.

요약하자면, $ 표기법(또는 유사한 제안)은 구문 및 의미론 문제를 크게 해결할 수 있는 동시에 컴파일러가 루프를 융합하고 SIMD를 활용하여 고성능 코드를 생성하는 데 필요한 정보를 제공할 수 있다고 생각합니다.

@lindahua 의 요약은 좋은 IMHO입니다.

그러나 이것을 더 확장하는 것이 재미있을 것이라고 생각합니다. Julia는 많은 공통 패턴을 풀린 루프만큼 효율적으로 만드는 야심 찬 시스템을 받을 자격이 있습니다.

• 중첩된 함수 호출을 단일 루프로 융합하는 패턴은 연산자에도 적용되어 A .* B .+ C 가 두 개의 임시 생성으로 이어지지 않고 결과에 대해 하나만 생성되도록 해야 합니다.
• 요소별 함수와 축소의 조합도 처리해야 각 요소의 값을 계산한 후 즉시 축소가 적용됩니다. 일반적으로 이렇게 하면 sumabs2(A) 를 제거하고 sum(abs$(A)$^2) (또는 sum(abs.(A).^2) )와 같은 표준 표기법으로 대체할 수 있습니다.
• 마지막으로 비표준 반복 패턴은 비표준 배열에 대해 지원되어야 하므로 희소 행렬의 경우 A .* B 는 0이 아닌 항목만 처리하고 희소 행렬을 반환하면 됩니다. 이는 요소별 함수를 Set , Dict 또는 Range 에 적용하려는 경우에도 유용합니다.

마지막 두 지점은 요소별 함수가 특별한 AbstractArray LazyArray 을 반환하도록 하여 작동할 수 있습니다 Transpose https://github.com/JuliaLang/julia/issues/4774#issuecomment-59422003에서 입력). 그러나 1 에서 length(A) 까지 선형 인덱스를 사용하여 순진하게 요소에 액세스하는 대신 반복자 프로토콜을 사용할 수 있습니다. 주어진 유형의 반복자는 유형의 저장소 레이아웃에 따라 행 단위 또는 열 단위 반복이 가장 효율적인지 여부를 자동으로 선택합니다. 그리고 희소 행렬의 경우 0 항목을 건너뛸 수 있습니다(원본과 결과는 공통 ​​구조를 가져야 합니다. https://github.com/JuliaLang/julia/issues/7010, https://github. com/JuliaLang/julia/issues/7157).

축소가 적용되지 않으면 원래의 것과 같은 유형 및 모양의 개체는 LazyArray ( collect 와 동일하지만 원래 배열의 유형을 존중함)를 반복하여 채워집니다. ). 이를 위해 필요한 유일한 것은 반복자가 LazyArray getindex 를 호출하고 결과에 대해 setindex! 를 호출하는 데 사용할 수 있는 객체를 반환한다는 것입니다(예: 선형 또는 데카르트 좌표).

축소가 적용되면 인수에 관련 반복 방법을 사용하여 LazyArray 의 필수 차원을 반복하고 결과로 배열을 채웁니다( reduce 와 동일하지만 배열 유형에 적응하기 위한 사용자 정의 반복자). 하나의 함수(마지막 단락에서 사용된 함수)는 가장 효율적인 방법으로 모든 요소에 대해 반복기를 반환합니다. 다른 사람들은 특정 차원에서 그렇게 할 수 있습니다.

이 전체 시스템은 내부 작업도 매우 간단하게 지원합니다.

나는 구문을 다루는 것에 대해 조금 생각하고 배열에 요소별 연산을 적용하기 위해 .= 를 생각했습니다.
따라서 @nalimilan 의 sum(abs.(A).^2)) 예제는 불행히도 두 단계로 작성되어야 합니다.

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

이것은 읽기 쉽다는 이점이 있으며 요소별 함수는 배열 특정 메소드를 작성하는 대신 단일(또는 다중) 입력에 대해서만 작성되고 해당 경우에 최적화되어야 함을 의미합니다.

물론 성능과 친숙함 외에는 언급된 대로 지금 당장 map((x) -> abs(x)^2, A) 를 쓰는 것을 막지 못합니다.

또는 .() 로 매핑할 표현식을 둘러싸면 작동할 수 있습니다.
이렇게 하는 것이 얼마나 어려운지 모르겠지만 .sin(x) 및 .(x + sin(x)) 는 괄호 안의 표현식이나 . 뒤에 오는 함수를 매핑합니다.
그러면 sum(.(abs(A)^2)) 를 한 줄로 작성할 수 있는 @nalimilan 의 예와 같은 축소가 가능합니다.

이 두 제안은 모두 내부적으로 브로드캐스트를 사용하는 동안 배열에 대한 요소별 연산을 생각하게 만든 . 접두사를 사용합니다. 이것은 $ 또는 다른 기호로 쉽게 바꿀 수 있습니다.
이것은 매핑할 모든 함수 주위에 맵 연산자를 배치하고 대신 전체 표현식을 그룹화하고 매핑되도록 지정하는 것의 대안일 뿐입니다.

나는 나의 마지막 코멘트에 노출된 LazyArray 아이디어를 실험했습니다: https://gist.github.com/nalimilan/e737bc8b3b10288abdad

이 개념 증명에는 구문상의 설탕이 없지만 (a ./ 2).^2 는 요지에서 LazyArray(LazyArray(a, /, (2,)), ^, (2,)) 로 작성된 것으로 번역됩니다. 시스템은 꽤 잘 작동하지만 성능과 관련하여 루프와 원격으로 경쟁하려면 더 많은 최적화가 필요합니다. (예상되는) 문제는 추가 인수가 허용되지 않는 버전에서도 12행의 함수 호출이 최적화되지 않은 것 같습니다(거의 모든 할당이 거기에서 발생함). 호출하는 함수에서 LazyArray 를 매개변수화해야 한다고 생각하지만 인수 처리는 고사하고 어떻게 그렇게 할 수 있는지 알지 못했습니다. 어떤 아이디어?

LazyArray 의 성능을 향상시키는 방법에 대한 제안 사항이 있습니까?

@nalimilan 나는 1년 전에 NumericFuns의 functor 유형을 사용하여 게으른 표현식 유형을 매개변수화하는 유사한 접근 방식을 실험했습니다. 다양한 트릭을 시도했지만 성능 격차를 메우는 데 운이 없었습니다.

컴파일러 최적화는 지난 1년 동안 점진적으로 개선되었습니다. 그러나 여전히 불필요한 오버헤드를 최적화할 수 없다고 생각합니다. 이런 종류의 일에는 컴파일러가 공격적인 인라인 함수를 필요로 합니다. @inline 를 사용해 보고 상황이 개선되는지 확인할 수 있습니다.

@lindahua @inline 는 타이밍에 차이를 만들지 않습니다 getindex(::LazyArray, ...) 는 주어진 LazyArray 서명에 특화되어 있기 때문에 논리적입니다. 이 서명은 어떤 기능을 사용해야 하는지 지정하지 않습니다. 불리다. getindex 컴파일할 때 호출을 알 수 있도록 호출해야 하는 F 함수와 함께 LazyArray{T1, N, T2, F} 와 같은 것이 필요합니다. 방법이 있나요?

인라인은 또 다른 큰 개선 사항이지만 현재로서는 인라인되지 않은 호출보다 타이밍이 훨씬 더 나쁩니다.

NumericFuns 사용을 고려할 수 있으며 F 는 펑터 유형이 될 수 있습니다.

다화

분산에 대한 반환 유형을 알고 있는 함수가 필요했습니다.
컴퓨팅, 여기서 결과 이전에 결과에 대한 참조를 생성합니다(및
따라서 그 유형)이 알려져 있습니다. 나는 매우 유사한 것을 직접 구현했으며
아마도 "Functors"라고 부르는 것을 사용하도록 전환해야 합니다. (싫어.
"functor"라는 이름은 일반적으로 다른 것이므로 <
http://en.wikipedia.org/wiki/Functor>, 하지만 C++이 물을 흐트러뜨린 것 같아요.
여기.)

Functor 부분을
수학 함수.

-에릭

2014년 11월 20일 목요일 오전 10시 35분, Dahua Lin [email protected]
썼다:

NumericFuns 사용을 고려할 수 있으며 F는 펑터 유형일 수 있습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8450#issuecomment -63826019.

에릭 슈 네터 [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@lindahua 나는 functor를 사용해 보았고 실제로 성능이 훨씬 더 합리적입니다.
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 를 사용하면 도움이 될 수 있습니다(해당되는 경우).

두 개의 연속 행이 mov RAX, ... 로 시작하는 아래 부분은 이중 간접 참조입니다. 즉, 포인터에 대한 포인터(또는 배열의 배열 또는 배열에 대한 포인터 등)에 액세스하는 것입니다. 이것은 LazyArray의 내부 표현과 관련이 있을 수 있습니다. 아마도 immutable을 사용하는 것(또는 Julia에 의해 immutable을 다르게 표현하는 것)이 도움이 될 것입니다.

어쨌든 코드는 여전히 매우 빠릅니다. 더 빠르게 만들려면 호출자에 인라인되어 추가 최적화 기회를 노출해야 합니다. 예를 들어 루프에서 이 표현식을 호출하면 어떻게 됩니까?

또한: REPL이 아니라 함수 내에서 이것을 디스어셈블하면 어떻게 됩니까?

또한 첫 번째 버전이 실제
두 번째는 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 후자의 경우 분할이 단순화되지 않는다는 것을 무엇으로 설명할 수 있습니까?

두 개의 인수 버전( 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)

따라서 이 전략은 .+ , .* 등의 연산자를 포함한 모든 요소별 연산을 대체하는 데 실행 가능한 것처럼 보입니다.

또한 행렬의 차원, 즉 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 감사합니다. 이것은 실제로 유사하지만 Julia가 명령형 모델을 사용하기 때문에 더 복잡합니다. 반대로 Haskell에서는 컴파일러가 매우 다양한 경우를 처리해야 하고 SIMD 문제도 처리해야 합니다(이는 Julia의 나중 시점에서 LLVM에 의해 처리됨). 하지만 솔직히 이 논문의 모든 것을 분석할 수는 없습니다.

@nalimilan 그 느낌 잘 압니다. 두 번째 논문이 특히 흥미로운 이유는 일반화된 스트림 퓨전(Generalized Stream Fusion)에 대해 논의했기 때문입니다. 이는 벡터에 대한 멋진 계산 모델을 분명히 허용합니다.

map 및 reduce 와 같은 구성이 게으름과 함께 충분히 빠를 수 있다는(또는 명시적 루프보다 빠를 수 있음) 여기서 우리가 취해야 하는 요점이라고 생각합니다.

내가 말할 수 있는 한, 중괄호는 여전히 호출 구문에서 사용할 수 있습니다. 이것이 func{x} 가 된다면? 어쩌면 조금 너무 낭비?

빠른 벡터링(SIMD의 의미에서) 주제에 대해 Eigen이 수행하는 방식을 모방할 수 있는 방법이 있습니까?

다음은 현재의 모든 요소별 연산을 위에서 LazyArray 및 LazyArray2 라고 하는 일반화로 대체하는 제안입니다. 이것은 물론 NumericFuns.jl의 펑터에 의존하지 않고 모든 함수에 대해 이것을 빠르게 만들 수 있다는 가정에 의존합니다.

1) $ x f() $를 호출하는 LazyArray 를 생성하는 새로운 구문 f.(x) 또는 f$(x) 또는 무엇이든 추가합니다.

2) broadcast 가 현재 작동하는 방식에 따라 이 구문을 일반화합니다. 예를 들어 f.(x, y, ...) 또는 f$(x, y, ...) 는 LazyArray 를 생성하지만 확장 싱글톤 차원은 x 입니다. y , ... 공통 크기를 제공합니다. 이것은 물론 인덱스에 대한 계산에 의해 즉석에서 수행되어 확장된 배열이 실제로 할당되지 않습니다.

3) .+ , .- , .* , ./ , .^ 등을 $ 대신 broadcast LazyArray 사용 broadcast .

4) 새로운 대입 연산자 .= 또는 $= 를 도입하여 collect 호출) LazyArray 를 실제 배열로 변환합니다. 승격 규칙을 통한 입력 및 입력의 요소 유형 및 호출된 함수에 따른 요소 유형).

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차원 이해는 모양을 유지하지 않지만 이제 for i in eachindex(x) 도 변경될 수 있습니다.

이해의 한 가지 문제는 DataArray를 지원하지 않는다는 것입니다.

LazyArray 아이디어와 매우 유사해 보이는 .Net에서 발생한 많은 일들을 살펴보는 것이 가치가 있을 수 있다고 생각합니다. 본질적으로 그것은 LINQ 스타일 접근 방식과 매우 유사해 보입니다. 여기서 우리가 지금 가지고 있는 요소별 항목처럼 보이는 구문을 가지고 있지만 실제로는 해당 구문이 표현식 트리를 구성하고 해당 표현식 트리가 나중에 어떤 효율적인 방식으로 평가됩니다. . 왠지 가깝죠?

.Net에서 그들은 이러한 식 트리를 여러 CPU에서 병렬로 실행하거나(.AsParallel()을 추가하여) DryadLINQ 또는 http:// 에서 대규모 클러스터에서 실행할 수 있습니다.

내 생각에는 Blaze도 그런 방향으로 가고 있다고 생각합니다. 즉, 계산을 설명하는 개체를 쉽게 구성할 수 있고 다른 실행 엔진을 사용할 수 있습니다.

이것이 명확하지는 않지만 이 전체 문제는 코드와 같은 낮은 수준의 효율적인 SIMD를 생성할 수 있는 방법과 이것이 GPU 컴퓨팅, 클러스터링, 병렬에 어떻게 사용될 수 있는지 모두의 맥락에서 살펴봐야 하는 것 같습니다. 계산 등

예, 더 긴 예에 점이 너무 많다는 것이 맞습니다. 그러나 두 개의 짧은 것이 더 일반적이며 이 경우 짧은 구문을 갖는 것이 중요합니다. 나는 게으름과 구문을 분리하고 싶지만 귀하의 의견에 따르면 매우 어려운 것처럼 보이므로 항상 두 가지를 혼합합니다!

y = [sqrt(x + 2) over x] 와 같은 이해 구문을 적용하는 것을 상상할 수 있습니다. 그러나 @johnmyleswhite 가 언급했듯이 DataArrays 는 물론 희소 행렬과 모든 새로운 배열 유형도 지원해야 합니다. 따라서 이것은 구문과 기능을 혼합한 경우입니다.

더 근본적으로 제 제안이 대안에 대해 제공하는 두 가지 기능은 다음과 같습니다.
1) y[:] = sqrt.(x .+ 2) 를 사용하여 할당 없는 제자리 할당 지원.
2) sum((x .- y).^2, 1) 와 같은 무할당 감소 지원.

다른 솔루션과 함께 제공될 수 있습니까(구문 문제 무시)?

@davidanthoff 감사합니다. 지금 살펴보고 있습니다( LazyArray 도 병렬 컴퓨팅을 지원하도록 만들 수 있다고 생각합니다).

아마도 이것은 Generator와 결합될 수 있습니다 — 그들은 또한 일종의 게으른 배열이기도 합니다. 나는 [f(x) over x] 이해 구문이 다소 마음에 듭니다. 비록 새 사용자에게는 개념적으로 어려울 수 있지만(동일한 이름이 요소와 배열 자체에 모두 사용되기 때문에) 개념적으로 어려울 수 있습니다. 대괄호가 없는 이해가 생성기를 생성한다면(내가 오래전 에 가지고 놀았던 것처럼), 대괄호가 없는 이러한 새로운 over-x-style-comprehensions를 사용하여 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 사이의 한 가지 차이점은 여러 반복자의 경우에 발생하는 일입니다. [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 ing이 매우 일반적이고 간결해야 하기 때문입니다.

이봐, 나는 구문에 대해 Jeff를 설득했습니다! ;-)

이것은 #4470 옆에 속하므로 지금은 0.4-projects에 추가합니다.

논의의 요지를 이해한다면 주요 문제는 다음과 같은 매핑과 유사한 구문을 원한다는 것입니다.

• 기본 배열뿐만 아니라 DataArray와 같은 다양한 데이터 유형과 함께 작동합니다.
• 수동으로 작성된 루프만큼 빠릅니다.

인라인을 사용하여 수행하는 것이 가능할 수도 있지만 인라인이 작동하는지 확인하는 데 정말 주의해야 합니다.

다른 접근 방식은 어떻습니까? 추론된 데이터 유형에 따라 매크로를 사용합니다. 데이터 구조가 DataArray임을 유추할 수 있으면 DataArrays 라이브러리에서 제공하는 맵 매크로를 사용합니다. 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)

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) )는 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)에 걸쳐 반복자로 로컬에서 도입되고 있음을 나타냅니다. 본질적으로 이것이 함수 수정에서 배열 또는 인덱스 수정으로 점 표기법을 전환한다고 가정합니다. 이렇게 하면 "점 크리프"에서 하나를 구할 수 있습니다. Jeff는 다음과 같이 말했습니다.

[ 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]))) ] ]

이해 구문의 한 가지 잠재적인 이점은 더 넓은 범위의 요소별 작업 패턴을 허용할 수 있다는 것입니다. 예를 들어, 파서가 x[m, .i] i 로 인덱싱하는 것이 암시적으로 모듈로 길이(x[m,:])라는 것을 이해한다면 다음과 같이 작성할 수 있습니다.

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

x 의 요소를 y 의 요소와 반대 순서로 곱하려면, 즉 y 의 마지막 요소에 대해 x 의 첫 번째 요소 등 하나는 쓸 수 있습니다

[ 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 스타일 재활용을 사용하는 벡터화 버전은 꽤 유용할 수 있습니다. 즉, 가장 큰 인수의 크기와 일치하지 않는 인수는 재활용을 통해 확장됩니다. 그런 다음 사용자는 인수 등의 수에 관계없이 원하는 모든 것을 쉽게 벡터화할 수 있습니다.

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: 이 작업을 수행하는 약간 더 우아한 방법 중 하나는 모드 인덱싱을 사용하여 특별한 유형의 배열을 정의하는 것입니다. 그건,

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 구문으로 함수를 정의하고 싶지는 않습니다. 그러면 익명 함수에 대한 이름의 상수가 아닌 바인딩이 생성됩니다. Julia에서는 일반 함수를 사용하는 것이 표준이며 함수에 대한 바인딩은 자동으로 일정합니다. 그렇지 않으면 끔찍한 성능을 얻게 됩니다.

왜 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)]

이 둘의 주요 차이점은 전자가 지도를 의미하기 때문에 모양 보존에 더 많은 제한이 있다는 것입니다.

over , range 및 window 에는 OLAP 공간에서 반복에 대한 수정자로 일부 선행 기술이 있으며 이는 일관된 것으로 보입니다.

나는 . 구문에 관심이 없습니다. 라인 노이즈에 대한 크리프처럼 보이기 때문입니다.

$는 아마도 일관되고, i,j를 표현식으로 반복하는 값을 인턴으로 합니까?

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

표현식의 자동 벡터화를 위해 표현식의 벡터 중 하나를 taint 할 수 없고 유형 시스템이 표현식을 벡터 공간으로 들어 올릴 수 있습니까?

나는 julia의 표현력으로 이미 쓸 수 있는 시계열 작업과 유사합니다.

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 ,

내가 올바르게 이해했다면 위에 언급된 의견에 대한 JuliaCon 2015 의견에 대한 해결책을 제안하고 싶습니다.
"[...] 그리고 라이브러리 작성자에게 모든 적절한 함수에 @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

그게 다야! 벡터화 가능한 함수에서 함수를 상속받으면 벡터화할 수 있습니다.

나는 당신이 찾고 있던 라인을 따라 이것을 바랍니다.

문안 인사,

엄마

다중 상속이 없는 경우 함수는 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 매크로의 "어리석음"에 대한 적절한 솔루션이 _아닌_ 것 같습니다.

문안 인사,

엄마

@johnmyleswhite :

귀하의 의견에 답하고 싶지만 제가 이해하지 못하는 것 같습니다. 명확히 할 수 있습니까?

내가 _할 수 있는_ 한 가지:
"Vectorizable"에는 특별한 것이 없습니다. 아이디어는 누구나 자신의 함수 "class"(예: MyFunctionGroupA<:Function )를 정의할 수 있다는 것입니다. 그런 다음 위에서 설명한 대로 고유한 "호출" 서명을 정의하여 해당 유형의 함수에 대한 호출을 포착할 수 있습니다.

제 제안은 벡터화된 알고리즘을 자동으로 생성하기 위해 Base 내에 정의된 함수가 Base.Vectorizable <: Function (또는 이와 유사한 것)를 사용해야 한다는 것입니다.

그런 다음 모듈 개발자가 다음과 같은 패턴을 사용하여 자체 기능을 구현하도록 제안합니다.

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

물론 promote_type(::Type{MyType},::Type{MyType}) 자체 버전을 제공해야 합니다. 기본값이 MyType 를 반환하지 않는 경우입니다.

기본 벡터화 알고리즘이 충분하지 않으면 사용자가 자신의 계층 구조를 구현하는 것을 막을 수 없습니다.

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

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

엄마

@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_ 벡터화 가능한 하위 유형을 (한 번만) 구현할 수 있습니다.

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 유형을 갖는 것은 여전히 ​​약간의 고통(그리고 약간 부적절함)이라는 것을 이해합니다... 그러나 적어도 Julia에서 성가신 반복(1) 중 하나를 제거할 것입니다(새로 _each_를 등록해야 함) @vectorize_Xarg에 대한 호출이 있는 함수).

(1) Julia가 함수에 대한 상속을 지원한다고 가정합니다 (예: myfunction(...)<: Vectorizable ) - v0.4.0에서는 나타나지 않습니다. Julia 0.4.0에서 작업한 솔루션은 해킹일 뿐입니다... 여전히 함수를 등록해야 합니다... @vectorize_Xarg를 호출하는 것보다 훨씬 낫지 않습니다.

엄마

나는 여전히 그것이 일종의 잘못된 추상화라고 생각합니다. "벡터화"할 수 있거나 해야 하는 함수는 특정 종류의 함수가 아닙니다. _Every_ 함수는 map 에 전달되어 이 동작을 제공합니다.

BTW, 내가 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는 입력되지 않은 함수를 이미 자동 벡터화합니다.

함수 내부에 사용된 + 연산자가 벡터화되어 있기 때문에 그렇게 보입니다.

그러나 나는 이 행동을 바꾸기가 너무 어렵지 않아야 한다고 생각합니다. 개인적으로 그런 포괄적인 기능을 만드는 것에 대해 어떻게 느끼는지 모르겠지만 그것이 당신이 원하는 것처럼 들립니다.

나는 당신의 예약을 공유합니다. 각 함수 자체가 호출될 때 수행할 작업을 말해주기 때문에 "여기에 모든 함수를 호출하는 방법이 있습니다"라고 정의할 수 없습니다. 이것이 바로 함수입니다!

나는 이렇게 말했어야 했다: ... 사용자 정의 비-유니코드 중위 연산자, 우리는 사용자가 이러한 핵심 기능에 액세스하기 위해 유니코드 문자를 입력하도록 요구하고 싶지 않기 때문입니다. $가 실제로 추가된 것 중 하나라는 것을 알지만, 감사합니다! 와우, 그래서 이것은 오늘날 Julia에서 실제로 작동합니다(비록 "빠르지는 않지만...아직"):

줄리아> ($) = 지도
줄리아> 죄 $ (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 화신에서 -> ) Julia에서도 마찬가지입니다. . 나는 이것이 오히려 혼란 스러울 것이라고 생각합니다.

수학에 대해 말하자면 ... 모델 이론에서 괄호가 없는 튜플에 함수를 적용하여 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 ). 동형(homomorphism) 등을 정의하는 데 유용한 구문이지만 프로그래밍 언어로 쉽게 전송할 수 있는 것은 아닙니다. :-}

\Mapsto 와 같은 다른 대안은 어떻습니까? => (Pair)와 혼동하시겠습니까? 여기에서 두 기호를 나란히 구분할 수 있다고 생각합니다.

• ->
• ↦

비슷하게 보이는 기호가 많이 있습니다. 매우 다르게 보이거나 순수한 ASCII만 사용하는 경우 기호가 그렇게 많은 이유는 무엇입니까?

나는 이것이 오히려 혼란 스러울 것이라고 생각합니다.

문서화와 경험이 이를 해결한다고 생각합니다. 동의하십니까?

기호와 같은 다른 화살표도 많이 있습니다. 솔직히 수학에서 무엇에 사용되는지 모르겠습니다. 이름에 map 가 있기 때문에 이 화살표만 제안했습니다! :웃다:

내 요점은 -> 가 ASCII에서 ↦ 를 나타내려는 Julia의 시도라는 것입니다. 따라서 ↦ 를 사용하여 다른 것을 의미하는 것은 바람직하지 않습니다. 육안으로 구분이 안되는건 아닙니다 :-)

내 직감은 우리가 잘 정립된 수학적 기호를 사용하려는 경우 최소한 Julia 용법이 기존 용법과 어떻게 다른지 생각해 보고 싶을 것입니다. 이름에 map 가 포함된 기호를 선택하는 것이 논리적으로 보이지만 이 경우 맵(또는 다른 유형의 맵 또는 그러한 맵의 유형)의 정의를 참조합니다. 이는 매개변수가 매핑되는 대상을 정의하여 전체 기능을 정의하는 대신 실제로 지정된 인수(매개변수 값)가 매핑되는 대상을 나열하는 Pair에서의 사용법에도 해당됩니다. 즉, 명시적으로 의 요소입니다. 열거 함수, 개념적으로(예: 사전).

@Ismael-VC 귀하의 제안에 대한 문제는 map 를 두 번 호출해야 하지만 이상적인 솔루션은 임시 배열을 포함하지 않고 map((a, b) -> sin(0.5 * abs2(a-b)), x, y) 로 줄이는 것입니다. 게다가 ↦ 를 두 번 반복하는 것은 시각적으로나 타이핑을 위해 좋지 않습니다(ASCII에 상응하는 것이 있으면 좋을 것입니다).

R 사용자는 이 아이디어를 싫어할 수 있지만 ~ 의 현재 중위 매크로 특수 사례 구문 분석을 더 이상 사용하지 않는 방향으로 이동하면(GLM 및 DataFrames와 같은 패키지는 공식 DSL, 참조 https:/를 매크로 구문 분석으로 변경해야 합니다. /github.com/JuliaStats/GLM.jl/issues/116), 그것은 중위 ASCII 연산자의 희귀한 상품을 해방시킬 것입니다.

a ~ b 는 기본에서 map(a, b) 로 정의할 수 있고 a .~ b 는 broadcast(a, b) 로 정의할 수 있습니까? 기존 중위 연산자로 구문 분석하면 R 공식 인터페이스의 에뮬레이션과 같은 매크로 DSL은 JuMP가 <= 및 == 로 수행하는 것처럼 매크로 내부의 연산자 해석을 자유롭게 구현할 수 있습니다. .

가장 좋은 제안은 아니지만 과도하게 사용하는 경우 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 문제에는 많은 양이지만 이 경우에는 분명히 충분하지 않음). 대체로 그다지 다른 제안이 없습니다. (동일한 개념의 사소한 변형이 아닙니다).

설문조사/설문조사(:충격:)를 만드는 아이디어가 마음에 들지 않거나 가치가 있다고 생각하는 분들이 계시다는 것을 압니다. 하지만 저는 이런 일에 대해 누구의 허락도 받을 필요가 없기 때문에 어쨌든 그렇게 할 것입니다. 우리 커뮤니티와 소셜 네트워크 및 다른 커뮤니티에서 최대한의 활용을 하지 않는 것이 좀 안타깝습니다. 또한 우리가 그 가치를 보지 못한다는 것이 더욱 안타깝습니다. 더 다양 하고 신선한 의견을 수집할 수 있는지, 아니면 최소한 확인을 해보자. 실험으로 이 특정 문제에 대한 현재 의견에 대해 대다수가 어떻게 느끼는지 확인하고 어떻게 진행되는지 확인하십시오. 어쩌면 정말 쓸모가 없을 수도 있고, 그렇지 않을 수도 있습니다. 정말 알 수 있는 방법은 한 가지뿐입니다.
</rambling>

@Ismael-VC: 정말 설문조사를 하고 싶다면 가장 먼저 해야 할 일은 묻고 싶은 질문을 신중하게 고려하는 것입니다. 모든 사람이 전체 스레드를 읽고 논의 대상이 된 옵션을 개별적으로 요약할 것이라고 기대할 수는 없습니다.

map(func, x) 는 map(v -> sin(0.5 * abs2(v)), x) 와 같은 것도 다룹니다. 이것이 이 스레드에서 논의한 내용입니다. 위에서 논의한 모든 제안을 염두에 두는 것이 더 어려울 수 있으므로 이것을 다른 스레드로 옮기지 맙시다.

map 를 사용하여 제네릭 함수를 적용하는 간단한 경우에 대해 구문을 추가하는 것을 반대하지는 않지만 그렇게 하면 더 넓은 그림을 동시에 고려하는 것이 좋은 생각이라고 생각합니다. 그렇지 않았다면 문제는 이미 오래전에 해결되었을 수 있습니다.

@Ismael-VC 여론 조사는 여기 IMHO에 도움이 되지 않을 것입니다. 우리는 여러 솔루션 중 어느 것이 가장 좋은지 찾으려고 하는 것이 아니라 아무도 실제로 찾지 못한 솔루션을 찾는 것입니다. 이 토론은 이미 길고 많은 사람들이 참여하고 있으므로 더 추가하는 것이 도움이 되지 않을 것이라고 생각합니다.

@Ismael-VC 괜찮습니다. 부담 없이 설문조사를 하세요. 사실 저는 과거에 문제에 대해 몇 가지 기념일 로고 투표를 했습니다(예: http://doodle.com/poll/s8734pcue8yxv6t4). 내 경험에 따르면 문제 스레드에서 논의하는 것보다 투표에서 투표하는 사람과 같거나 더 적은 수입니다. 매우 구체적이고 종종 피상적인/구문 문제에 적합합니다. 그러나 당신이 할 수 있는 모든 것이 기존 옵션 중에서 선택하는 것뿐인데 어떻게 설문조사가 참신한 아이디어를 생성할 수 있겠습니까?

물론 이 문제의 실제 목표는 암시적으로 벡터화된 함수를 제거하는 것입니다. 이론상 map 구문이면 충분합니다. 왜냐하면 이러한 모든 함수는 모든 경우에 map 를 수행하기 때문입니다.

이를 위해 기존의 수학 표기법을 찾아보았지만, 표기법을 사용하기에는 연산이 너무 중요하지 않다는 의견을 보는 경향이 있습니다! 수학적 맥락에서 임의의 함수의 경우 나는 이것을 거의 믿을 수 있습니다. 그러나 가장 가까운 것은 몇 가지 일반화가 있는 Hadamard 제품 표기법인 것 같습니다. https://en.wikipedia.org/wiki/Hadamard_product_ (matrix)#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-complexed-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은 요소별 연산(예: > , LN )과 감소(예: SUM )를 구별하는 구문을 제공하지 않습니다. 후자는 현재 Julia에서와 같이 단순히 자동으로 벡터화됩니다.

@JeffBezanson \circ 사용의 장점은 인덱스 집합을 인덱스 집합의 함수로 해석하면(표준 수학적 "구현") 매핑이 _is_ 간단하게 구성된다는 것입니다. 따라서 (sin ∘ x)(i)=sin(x(i)) , 또는 오히려 sin(x[i]) .

@mdcfrancis 가 언급했듯이 파이프의 사용은 본질적으로 수학에서 (또는 특히 범주 이론의 CS 응용 프로그램) 세미콜론으로 종종 수행되는 "다이어그램 순서" 구성일 것입니다. 그러나 우리는 이미 파이프를 가지고 있습니다. 물론 운영자입니다.

이러한 구성 연산자 중 어느 것도 문제가 없으면 다른 연산자를 사용할 수 있습니다. 예를 들어, 최소한 일부 저자는 추상 화살표/모피즘 구성에 낮은 \cdot 를 사용합니다. 기본적으로 화살표의 그룹형(다소 적게)의 "곱셈"이기 때문입니다.

그리고 ASCII 아날로그를 원하는 경우: 실제로 곱셈을 나타내기 위해 마침표를 사용하는 저자도 있습니다. (나는 그것을 작곡에도 사용하는 것을 보았을 수도 있습니다. 기억이 나지 않습니다.)

따라서 sin . x ... 하지만 혼란스러울 수 있습니다.

여전히 ... 마지막 비유는 정말 초기 제안 중 하나, 즉 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)]

이는 배열 구성을 위한 구문을 방해하지 않는 적어도 하나의 맵 구문에 동기를 부여합니다. :: 또는 table 확장 프로그램 f[::(A,B)] = [f(a[i], b[j]) for i in 1:n, j in 1:n] 은 적어도 두 번째 흥미로운 사용 사례로 이어집니다.

질문하려는 질문을 신중하게 고려하십시오.

@toivoh 감사합니다. 저는 현재 여러 설문조사/설문조사 소프트웨어를 평가하고 있습니다. 또한 나는 선호하는 구문 에 대해서만 폴링할 것입니다. 전체 스레드를 읽고 싶은 사람들은 그냥 그렇게 할 것입니다. 다른 누구도 그렇게 하는 데 관심이 없을 것이라고 가정하지 말자.

아무도 실제로 찾지 못한 해결책을 찾으십시오

@nalimilan 우리 중에 아무도 없습니다. :웃다:

당신이 할 수 있는 모든 것이 기존 옵션 중에서 선택하는 것뿐인데 어떻게 설문조사가 참신한 아이디어를 생성할 것입니까?
이슈 스레드에서 토론하는 것보다 투표에서 투표하는 사람과 같거나 더 적은 사람들이 있습니다.

@JeffBezanson 이미 설문조사를 하셨다니 기쁩니다. 계속 진행하세요!

• 귀하의 투표를 어떻게 홍보해 오셨습니까?
• 내가 지금까지 평가한 설문조사/설문조사 소프트웨어에서 kwiksurveys.com은 사용자가 _이 옵션 중 어느 것도 나를 위한 것이 아닙니다_ 옵션 대신 자신의 의견을 추가할 수 있도록 합니다.

sin∘x 유니코드가 필요하고 널리 알려져 있지 않기 때문에 그다지 도움이 되지 않는 것 같습니다.

우리는 유니코드가 너무 많아서 사용합시다. 탭 완성과 함께 사용하는 좋은 방법도 있습니다. 그때 사용하는 것이 잘못된 점은 무엇입니까?, 모르면 문서화하고 교육합시다. 존재하지 않으면 무엇이 문제입니까? 그것을 발명? 다른 사람이 그것을 발명하고 그것을 사용하여 선례로 받아들인 후에야 고려할 수 있도록 우리가 정말로 기다려야 합니까?

∘ 는 선례가 있는데 문제는 유니코드인가요? 왜요? 그러면 널리 알려지지 않은 나머지 유니코드를 언제 사용하기 시작합니까? 절대?

그 논리에 따르면 Julia는 어쨌든 널리 알려져 있지 않지만 배우고 싶은 사람은 알 것입니다. 내 매우 겸손한 의견으로는 나에게 의미가 없습니다.

충분히 공평합니다. 저는 ∘ 에 전적으로 반대하지 않습니다. 아주 기본적인 기능을 사용하기 위해 유니코드를 요구하는 것은 이에 대한 하나의 표시일 뿐입니다. 완전히 가라앉힐 만큼 충분하지는 않습니다.

* 를 ASCII 대안으로 사용/오버로드하는 것은 완전히 미친 짓입니까? 수학적으로 어느 정도 의미가 있다고 주장할 수는 있지만 때때로 그 의미를 식별하기 어려울 수 있다고 생각합니다... (다시, map 기능으로 제한되면 map 는 이미 ASCII 대안입니다. 아니요?)

\circ 사용의 장점은 인덱스 집합을 인덱스 집합의 함수로 해석하면(표준 수학적 "구현") 매핑이 _is_ 간단하게 구성된다는 것입니다.

내가 이것을 샀는지 확신이 서지 않는다.

@hayd 어느 부분인가요? 인덱싱된 패밀리(예: 시퀀스)는 인덱스 세트의 함수로 볼 수 있습니까? 아니면 이에 대한 매핑이 구성이 됩니까? 아니면 이것이 이 경우에 유용한 관점입니까?

처음 두 개의 (수학적) 요점은 논쟁의 여지가 거의 없다고 생각합니다. 하지만, 예, 여기에서 이것을 사용하는 것을 강력하게 옹호하지는 않을 것입니다. 대부분 "아, 그 정도가 적당합니다!"였습니다. 반응.

@mlhetland |>는 ->에 매우 가깝고 오늘날 작동합니다. 또한 올바른 연관이라는 '장점'이 있습니다.

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

@mdcfrancis 물론입니다. 그러나 그것은 내가 머리에 요약한 구성 해석을 뒤집습니다. 즉, sin∘x 는 x |> sin , 아니요?

추신: 아마도 "대수학"에서 길을 잃었을 수도 있지만 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 죄 |> x === 맵( 죄, 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, 2]를 _로 바꾸면 대신 익명 함수를 빌드할 수 있습니다. 참고 나는 연결을 위해 R의 magrittr 규칙을 사용하고 있습니다(연결 스레드에서 내 게시물 참조).

아마도 이것은 DSL처럼 보이기 시작했을 것입니다.

나는 이 문제를 오랫동안 추적해 왔으며 지금까지 언급하지 않았지만 이것은 IMHO의 손에서 벗어나기 시작했습니다.

나는 map에 대한 깨끗한 구문이라는 아이디어를 강력하게 지지합니다. 저는 @tkelman 의 ~ 제안이 이러한 기본 기능을 위해 ASCII 내에서 유지되는 것을 가장 좋아하고 sin~x 을 아주 좋아합니다. 이렇게 하면 위에서 논의한 바와 같이 매우 정교한 한 줄짜리 스타일 매핑이 가능합니다. sin∘x 를 사용해도 괜찮습니다. 더 복잡한 것의 경우 적절한 루프가 훨씬 더 명확하다고 생각하는 경향이 있습니다(일반적으로 최상의 성능). 나는 너무 많은 '마법 같은' 방송을 좋아하지 않습니다. 그것은 코드를 따라가기 훨씬 더 어렵게 만듭니다. 명시적 루프는 일반적으로 더 명확합니다.

그것은 그러한 기능이 추가되어서는 안 된다는 말은 아니지만, 특히 매우 빨라질 것이기 때문에 간결한 map 구문을 먼저 만들어 보겠습니다( jb/functions 분기에 대한 내 테스트에서) .

jb/functions의 효과 중 하나는 broadcast(op, x, y) 가 op 에 대한 방송을 수동으로 전문화한 사용자 정의 버전 x .op y 만큼 좋은 성능을 갖는다는 것입니다.

더 복잡한 것의 경우 적절한 루프가 훨씬 더 명확하다고 생각하는 경향이 있습니다(일반적으로 최상의 성능). 나는 너무 많은 '마법 같은' 방송을 좋아하지 않습니다. 그것은 코드를 따라가기 훨씬 더 어렵게 만듭니다. 명시적 루프는 일반적으로 더 명확합니다.

동의하지 않습니다. exp(2 * x.^2) 는 완벽하게 읽을 수 있으며 [exp(2 * v^2) for v in x] 보다 덜 장황합니다. 여기서 IMHO의 문제는 전자(복사본을 할당하고 작업을 융합하지 않음)를 사용하도록 하여 사람들을 가두는 것을 피하는 것입니다. 이를 위해 느린 형식이 더 이상 사용되지 않을 수 있도록 충분히 짧은 구문을 찾아야 합니다.

더 많은 생각. 함수를 호출할 때 할 수 있는 몇 가지 가능한 작업이 있습니다.

인수 없이 루프(체인)
연결된 인수만 반복합니다(맵).
모든 인수를 통해 루프(mapall)

위의 각 항목은 다음과 같이 수정할 수 있습니다.
반복할 항목 표시(~)
반복되지 않는 항목 표시([ ]의 추가 세트)

통합할 수 있는 항목은 구문을 무시하고 자동으로 처리되어야 합니다.
반복되는 인수가 두 개 이상 있는 경우 싱글톤 차원 확장이 자동으로 발생해야 합니다.

방송은 차원이 있었을 때만 차이가 있습니다.
그렇지 않으면 불일치. 그래서 방송하지 말라고 하면
대신 인수의 크기가 일치하지 않으면 오류가 발생합니까?

sin[x...]는 실제로 sin(x) 또는 sin~x 등에 대한 자세한 정보를 잃습니다.

또한 계속 생각해보면 sin[x...] 맵은 [f(x...)] 에서 덜 열성적인 버전입니다.
구문

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

또는 [exp(2 * (x..)^2)] 와 같은 유사한 것을 사용할 수 있으며 실제 암묵적 함수 연결이 도입되면 자체 설명합니다.

@nalimilan 네, 하지만 루프 없이도 괜찮다고 말한 내 '한 줄짜리' 범주에 맞습니다.

우리가 원하는 모든 것을 나열하는 동안: 할당 또는 복사 없이 할당할 수 있는 map 의 결과가 저에게 훨씬 더 중요합니다. 이것이 내가 여전히 성능에 중요한 코드에 대해 루프를 선호하는 또 다른 이유이지만, 이것이 완화될 수 있다면(#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

나는 계속 그것에 대해 생각했고 마침내 배열 이해에서 파생된 배열을 매핑하기 위한 일관되고 줄리안 구문을 알아냈다고 생각합니다. 다음 제안은 이미 확립된 배열 이해 언어를 기반으로 하기 때문에 julian입니다.

1. 실제로 @Jutho 가 제안한 f[a...] 부터 컨벤션
   벡터 a, b에 대해

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

새로운 기호를 도입하지 않습니다.

2.) 이것에 덧붙여, 나는 하나의 추가 연산자의 도입을 제안할 것입니다: _모양 보존_ 튀기는 연산자 .. (말하자면). ... 는 _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 구문의 장점 중 하나는 표현식과 함께 작동하는 방식입니다.

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

글쎄, 당신이 그것을 허용하려면 위의 [sin(x.. * y..)] 또는 sin[x.. * y..] 를 통해 가능합니다. 나는 그것이 컨테이너가 아닌 요소에 대한 함수 연산자에 대한 시각적 힌트를 제공하기 때문에 over 구문보다 조금 더 좋아합니다.

그러나 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 .

또 다른 가능성은 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) 를 사용하는 것입니다(" . f(x^2)-x over x vectorized" 관용구가 꽤 일반적입니다). 더 복잡한 표현식의 경우

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 를 제거할 수 있습니다. 그 후에 map 및 내포의 보다 일반적인 사용을 축약하기 위해 over (또는 무엇이든)와 같은 구문 작업을 계속할 수 있습니다.

@stevengj - 가 브로드캐스트되지 않기 때문에 두 번째 예제가 작동하지 않는다고 생각합니다. A 가 행렬이라고 가정하면 출력은 단일 행 행렬의 행렬이 됩니다. 각 행렬은 A 요소의 로그에서 첫 번째 차원의 합계 벡터를 뺀 것입니다. broadcast((x, y)->exp(log(x)-y), A, sum(A, 1)) 가 필요합니다. 하지만 map 에 대한 간결한 구문을 갖는 것이 유용하고 broadcast 에 대해서도 간결한 구문일 필요는 없다고 생각합니다.

sin 와 같이 역사적으로 자동 벡터화된 함수는 새 구문에서도 계속 유지됩니까, 아니면 더 이상 사용되지 않습니까? 나는 f. 구문조차도 개념적 우아함 논쟁에 의해 동기가 부여되지 않은 많은 과학 프로그래머들에게 '곤란'처럼 느껴질까 걱정됩니다.

내 생각에 sin 와 같은 역사적으로 벡터화된 함수는 sin. 를 위해 더 이상 사용되지 않지만 다음 릴리스에서 완전히 제거되는 것과는 대조적으로 준영구적으로 사용되지 않아야 합니다. 다른 과학 언어 사용자의 이점.

f.(args...) 에 대한 한 가지 사소한(?) 문제: object.(field) 구문은 대부분 거의 사용되지 않고 큰 고통 없이 getfield(object, field) 로 대체될 수 있지만 Base.(:+)(....) = .... 형식의 메서드 정의/참조가 _lot_이고 이를 getfield 로 변경하는 것은 고통스러울 것입니다.

한 가지 해결 방법은 다음과 같습니다.

• 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) 를 쓰는 것에 찬성하여 좋은 주장을 했다고 생각합니다. 그래서 길을 닦았다고 합니다.

이 구문을 복합 표현식으로 효율적으로 일반화할 수 있는 솔루션이 아직 없다는 사실에 대해 한 가지 유보했습니다. 그러나 이 단계에서 이 논의를 무기한 미해결 상태로 유지하는 것보다 대부분의 사용 사례를 다루는 이 기능을 병합하는 것이 더 낫다고 생각합니다.

@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) 보다 더 나은 옵션을 볼 수 없습니다. ~ 와 같은 임의의 기호를 선택하는 것보다 낫고 .* 등에 익숙한 많은 사람들은 그것이 의미하는 바를 바로 추측할 수도 있을 것입니다.

내가 더 잘 이해하고 싶은 한 가지는 사람들이 기존의 벡터화된 정의를 .( _교체_해도 괜찮은지 여부입니다. 사람들이 교체를 할 만큼 마음에 들지 않는다면 더 주저할 것입니다.

이 토론에 숨어 있는 사용자로서 저는 이것을 사용하여 기존의 벡터화된 코드를 대체하고 싶습니다.

루프가 빠르기 때문에 가독성을 위해 julia에서 벡터화를 주로 사용합니다. 그래서 저는 이전에 언급했듯이 exp, sin 등에 많이 사용하는 것을 좋아합니다. 나는 이미 .^, .*를 죄에 여분의 점을 추가하는 표현에서 사용할 것입니다. 특급 등은 나에게 정말 자연스럽고 훨씬 더 명확하게 느껴집니다. 특히 sin(x)와 map(f, x)을 혼합하는 대신 일반 표기법으로 내 자신의 함수를 쉽게 접을 수 있을 때 더욱 그렇습니다.

말하자면 일반 사용자로서 이것이 병합되기를 진심으로 바랍니다!

나는 fun.(vec) 보다 제안된 fun[vec] 구문을 더 좋아합니다.
[fun vec] 에 대해 어떻게 생각하세요? 목록 이해와 비슷하지만 암시적 변수가 있습니다. T[fun vec] 를 할 수 있습니다.

이 구문은 길이가 > 1인 벡터에 대해 Julia 0.4에서 무료입니다.

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)의 유형 계산의 어려움이 해결되면 ⧆ 연산자에 대한 a .⧆ b $#$가 설탕일 뿐이도록 또 다른 PR을 만들고 싶습니다. 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 , 루프 퓨전은 함수가 @pure 로 표시된 경우(적어도 eltypes가 변경할 수 없는 경우) 가능한 것처럼 보이지만 #15032에서 언급했듯이 이것은 컴파일러를 위한 작업이지, 파서. (그러나 이와 같은 벡터화된 구문은 중요한 내부 루프에서 마지막 주기를 짜내는 것보다 더 편리합니다.)

여기서 핵심 목표는 @vectorized 함수의 필요성을 제거하는 것입니다. 이를 위해서는 최소한 일반적으로, 거의 편리하고, 최소한 빠른 구문이 필요합니다. 자동화된 루프 퓨전이 필요하지는 않지만 사용자의 broadcast 의도를 컴파일러에 노출시켜 미래의 루프 퓨전 가능성을 여는 것이 좋습니다.

루프 퓨전도 하면 단점이 있나요?

@yuyichao , 루프 융합은 훨씬 더 어려운 문제이며 순수하지 않은 함수를 제외하더라도 항상 가능한 것은 아닙니다(예: 위의 @StefanKarpinski 의 exp(log(A) .- sum(A,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 broadcast syntax_ 제안에서 (내가 점점 더 좋아하는) 융합은 " stop"을 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: 이 토론에는 실제로 직교하는 두 가지 개념이 함께 모여 있습니다.
matlab'y "융합 방송 작업" 또는 x .* y .+ z 및 f[product(I,J)...] 및 f[zip(I,J)...] 와 같은 "제품 및 zip에 대한 매핑". 서로의 과거 이야기도 그와 관련이 있을 수 있습니다.

@mschauer , $# I 와 J 가 같은 모양이면 f.(I, J) 는 이미 (#15032에서) map(x -> f(x...), zip(I, J) $ 와 같습니다. I 가 행 벡터이고 J 가 열 벡터이거나 그 반대인 경우 broadcast 는 실제로 제품 세트에 매핑됩니다(또는 f.(I, J') 둘 다 1d 배열인 경우). 그래서 나는 당신이 개념이 "매우 직교적"이라고 생각하는 이유를 이해하지 못합니다.

Orthogonal은 올바른 단어가 아니라 공존할 수 있을 정도로 다릅니다.

그러나 요점은 두 경우에 대해 별도의 구문이 필요하지 않다는 것입니다. func.(args...) 는 둘 다 지원할 수 있습니다.

삼두(Stefan, Jeff, Viral)의 구성원이 #15032(병합 준비가 된 것으로 생각됨)를 병합하면 이를 닫고 로드맵 문제를 제출하여 나머지 제안된 변경 사항을 간략하게 설명합니다. 브로드캐스트 유형 계산 수정, 사용 중단 @vectorize , .op 를 브로드캐스트 설탕으로 바꾸고 구문 수준 "broadcast-fusion"을 추가하고 마지막으로 제자리 할당과 융합합니다. 마지막 두 개는 아마도 0.5가 되지 않을 것입니다.

안녕하세요, 저는 15032에 대해 매우 행복하고 감사합니다. 그래도 토론을 무시하지는 않겠습니다. 예를 들어 벡터 및 유사한 객체의 벡터는 줄리아에서 사용하기에는 여전히 매우 어색하지만 이해의 결과로 잡초처럼 싹이 틔울 수 있습니다. 싱글톤 차원으로의 반복 인코딩을 기반으로 하지 않는 좋은 암시적 표기법은 예를 들어 flexed out iterator 및 새로운 생성기 표현식과 같이 이것을 많이 완화할 가능성이 있습니다.

나는 이것이 #16285에 찬성하여 지금 닫을 수 있다고 생각합니다.