Ref. # 9930, # 20053, # 23552. 베스트!

참조 해 주셔서 감사합니다. 이 문제는 API 개편보다 gemm 스타일 메서드를 추가하는 것과 더 관련이 있다고 생각하지만 여전히 # 9930과 너무 비슷하다고 생각되면 닫을 수 있습니다.

시작점으로 _generic_matmatmul! 에 gemm API가있는 것에 대한 지원이 있습니까? 현재 메서드는 α=1 및 β=0 하여 구현되기 때문에 상당히 간단한 변경 사항이며 순전히 가산 / 비 브레이킹입니다. PR을 할 수 있습니다. 나는 아마도이 버전 과 비슷하게 갈 것입니다 (그 버전에서는 필요하지 않았기 때문에 모든 트랜스 포즈를 잘라 냈습니다. 여기서는하지 않을 것입니다).

예. 좋은 시작이 될 것입니다. 하지만 인수의 순서를 고려해야합니다. 원래는 BLAS 순서를 따르는 것이 더 자연 스럽다고 생각했지만 출력 인수를 먼저 갖는 것에 대해 상당히 일관 적이며 현재의 세 인수 A_mul_B! 의 경우이기도합니다. 또한 이미 지적했듯이 3 개 인수 버전은 α=1 및 β=0 및 기본값 인수가 마지막 인 5 개 인수 버전에 해당합니다. 물론이를 위해 반드시 기본값 구문을 사용할 필요는 없지만 여기서 사용하는 것이 합리적입니다.

왜 일반적인 gemm 함수를 도입하지 않습니까?

예. 좋은 시작이 될 것입니다. 하지만 인수의 순서를 고려해야합니다. 원래는 BLAS 순서를 따르는 것이 더 자연 스러웠다 고 생각했지만 출력 인수를 먼저 갖는 것에 대해 상당히 일관 적이며 현재의 3 개 인수 A_mul_B!의 경우이기도합니다. 또한 이미 지적했듯이 3 개 인수 버전은 α = 1 및 β = 0 인 5 개 인수 버전에 해당하며 기본값 인수는 마지막입니다. 물론이를 위해 반드시 기본값 구문을 사용할 필요는 없지만 여기서 사용하는 것이 합리적입니다.

좋아. # 9930에서 실제 인수 순서 및 메서드 이름 변경에 대한 논의를 계속할 수 있습니다. 나는 현재하겠습니다 이렇게하면 더 많은 단지 다섯 인수 버전을 사용할 필요 약 Ax_mul_Bx!(α,A,B,β,C) 인터페이스를.

왜 일반적인 gemm 기능을 도입하지 않습니까?

위의 변경 사항 외에 _generic_matmatmul! 을 gemm! 로 변경 하시겠습니까?

더 명확하게 말하면, 우리는 mul(C,A,B,α=1,β=0) 단일 메소드와 함께 디스패치 할 게으른 전치 / 접근 유형을 가져야한다고 생각하지만 다른 PR이 될 것입니다.

왜 일반적인 gemm 기능을 도입하지 않습니까?

줄리아에서 gemm 은 잘못된 이름이라고 생각합니다. BLAS에서 ge 부분은 행렬이 일반적 임을 나타냅니다. 즉, 특별한 구조가없고, 첫 번째 m 는 곱하고 m 목록은 행렬 입니다. Julia에서 ge (일반) 부분은 마지막 m (매트릭스)와 같이 서명에 인코딩되므로 mul! 라고 부르면됩니다.

SparseArrays.jl의 표기법 mul!(α, A, B, β, C) 입니다.

https://github.com/JuliaLang/julia/blob/160a46704fd1b349b5425f104a4ac8b323ea85af/stdlib/SparseArrays/src/linalg.jl#L32

공식 구문으로 "완료"? 그리고 이것은 mul!(C, A, B) , lmul!(A, B) 및 rmul!(A,B) ?

저는 A , B , C 을 (를) 다른 주문으로 사용하는 것을 좋아하지 않습니다.

SparseArrays.jl의 표기법 mul!(α, A, B, β, C) 가 공식 구문으로 "finalised"입니까?

아니오라고 말하고 싶습니다. 원래 BLAS를 따르는 아이디어가 마음에 들었습니다 (그리고 순서도 일반적으로 수학적으로 작성되는 방식과 일치했습니다).하지만 이제는 스케일링 인수를 선택적인 네 번째 및 다섯 번째 인수로 추가하는 것이 합리적이라고 생각합니다.

그래서 명확히하기 위해, 당신은 의미에서 선택적 인수를 원합니다.

function mul!(C, A, B, α=1, β=0)
 ...
end

다른 옵션은 선택적 키워드 인수입니다.

function mul!(C, A, B; α=1, β=0)
...
end

하지만 사람들이 유니 코드에 너무 만족하는지 잘 모르겠습니다.

나는 유니 코드에 매우 만족하지만 우리가 항상 ascii 옵션을 가지고 있다는 것은 사실이며 여기서 가능할 것입니다. 이름 α 및 β 또한 BLAS를 알지 않는 한 매우 직관적이지 않으므로 여기에서 위치 인수를 사용하는 것이 더 나은 솔루션이라고 생각합니다.

제 생각에는 더 논리적 인 명명법은 muladd!(A, B, C, α=1, β=1) 를 곱셈 과 덧셈 을 수행하는 다양한 BLAS 루틴에 매핑하는 gemm 또한 상기와 같은, 그러나 예를 들어 axpy 경우 A 스칼라이다.)

mul! 함수는 모든 중간 결과가 Y에 저장 될 수있는 한 임의의 수의 인수 ( * 처럼)를 취하는 mul!(Y, A, B, ...) 와 같은 인터페이스를 가질 수 있습니다. 선택적 kwarg는 적절한 기본값으로 곱셈 순서를 지정할 수 있습니다.)

mul!(Y, A::AbstractVecOrMat, B:AbstractVecOrMat, α::Number) 는 두 개의 행렬 / 벡터 및 스칼라의 다른 순열처럼 기본 구현 muladd!(A, B, Y, α=α, β=0) 갖습니다.

고밀도 행렬에 대해 정의 된 mul!(C, A, B, α, β) 에 대한 또 다른 투표. 이를 통해 조밀하고 희소 행렬에 대한 일반 코드를 작성할 수 있습니다. 비선형 최소 제곱 패키지에서 이러한 함수를 정의하고 싶었지만 이것이 유형 불법 복제라고 생각합니다.

나는 또한 MixedModels 패키지에 대한 mul!(C, A, B, α, β) 메서드를 작성하고 약간의 유형의 불법 복제에 참여하고 싶은 유혹을 받았지만 이러한 메서드가 LinearAlgebra 있으면 훨씬 더 좋을 것입니다. 꾸러미. 이 작업에 대한 muladd! 제네릭에 대한 메서드가 있으면 나도 괜찮을 것입니다.

나는 그것이 단지 mul! 과 다른 이름을 가져야한다고 생각하지만 나는 호의적이다. muladd! 은 합리적으로 보이지만 확실히 제안에 개방적입니다.

곱하기 증가를 위해 mulinc! 일까요?

addmul!(C, A, B, α=1, β=1) 같은 것을 가질 수 있습니다.

muladd! 아닙니까? 아니면 그것을 addmul! 라고 부르는 아이디어가 multiply 인수가 아닌 add 인수를 변경하는 것입니까? 곱하기 인수를 변형시킬 수 있습니까?

예를 들어 lmul! 및 ldiv! 와 같은 경우에 첫 번째가 아닌 요소를 변경하므로 일반적인 "muladd"순서 (예 : muladd!(A,B,C) )로 수행 할 수 있습니다. 문제는 α 및 β 주문이 무엇인지입니다. 한 가지 옵션은 키워드 인수를 만드는 것입니까?

스칼라 α와 β의 유형에 대한 옵션을 구현 자에게 남겨두면 좋지 않을까요? 최종 사용자를 위해 설탕을 추가하는 것은 쉽습니다.

α , β 기본값을 사용하여 이미 mul!(C, A, B, α, β) 에 정산했다고 생각했습니다. 이 버전은 https://github.com/JuliaLang/julia/blob/b8ca1a499ff4044b9cb1ba3881d8c6fbb1f3c03b/stdlib/SparseArrays/src/linalg.jl#L32 -L50에서 사용하고

감사! 그것이 문서화되어 있다면 좋을 것입니다.

α , β 기본값을 사용하여 이미 mul!(C, A, B, α, β) 에 정산했다고 생각했습니다.

SparseArrays는 그것을 사용하지만 어디에서나 논의 된 것을 기억하지 못합니다.

어떤면에서 muladd! 이름은 곱셈에 이어 더하기 때문에 더 자연 스럽습니다. 그러나 α 및 β의 기본값 인 muladd!(C, A, B, α=1, β=0) (β의 기본값은 1이 아니라 0 임)은 다시 mul!(C, A, B) .

이것을 mul! 또는 muladd! 호출할지 여부는 pedantry 대 일관성의 경우로 보이며 SparseArrays의 기존 메서드의 경우 mul! 주장 할 것이라고 생각합니다. 나는 내가 좋아하는 Oscar Wilde 인용구에도 불구하고 일관성을 주장하는 호기심 많은 경우에있다. "일관성은 상상력이없는 사람들의 마지막 피난처이다."

어떤면에서 muladd! 이름은 곱셈에 이어 더하기 때문에 더 자연 스럽습니다. 그러나 α 및 β의 기본값 인 muladd!(C, A, B, α=1, β=0) (β의 기본값은 1이 아니라 0 임)은 다시 mul!(C, A, B) .

C 에 Infs 또는 NaN이 포함되어있을 때 흥미로운 예외가 있습니다. 이론적으로 β==0 이면 결과는 여전히 NaN이어야합니다. BLAS와 희소 행렬 코드 가 β==0 를 명시 적으로 확인한 다음 0으로 대체하기 때문에 이것은 실제로 발생하지 않습니다.

true 및 false 는 true*x 가 항상 x 라는 점에서 true 및 false 가 각각 "strong"1과 0이므로 α=true, β=false 기본값을 갖는 것으로 간주 할 수 있습니다 x 및 false*x 는 항상 zero(x) 입니다.

lmul! 에도 예외적 인 동작이 있어야합니다 : https://github.com/JuliaLang/julia/issues/28972

true 및 false 는 true*x 가 항상 x 이고 false*x 가 항상 zero(x) 라는 점에서 각각 "강력한"1과 0입니다.

나는 그것을 몰랐다! :

julia> false*NaN
0.0

FWIW,이 작업에 대한 LazyArrays.jl 구문의 가독성에 매우 만족합니다.

y .= α .* Mul(A,x) .+ β .* y

BLAS 호환 배열 (banded 및 strided)의 경우 배후에서 mul!(y, A, x, α, β) 낮아집니다.

나는 그것을 몰랐다!

그것은 im = Complex(false, true) 작동하게 만드는 요소의 일부입니다.

SparseArrays는 그것을 사용하지만 어디에서나 논의 된 것을 기억하지 못합니다.

위의 https://github.com/JuliaLang/julia/issues/23919#issuecomment -365463941에서 논의되었으며 이의없이 https://github.com/JuliaLang/julia/pull/26117 에서 구현되었습니다. 밀도가 높은 경우에는 α,β 버전이 없으므로이 리포지토리에서 결정이 즉각적인 영향을 미치는 유일한 위치는 SparseArrays 입니다.

LinearAlgebra.BLAS.gemm! 어떻습니까? 5 진 mul! 로 래핑되어야하지 않나요?

그래야하지만 아직 아무도하지 않았습니다. matmul.jl 에는 많은 메소드가 있습니다.

위의 # 23919 (코멘트) 에서 논의되었으며 이의없이 # 26117에서 구현되었습니다.

이건 내 반대라고 생각해 다른 이름을 선호합니다.

왜 다른 이름일까요? 조밀 한 경우와 희소 한 경우 모두 기본 알고리즘이 곱셈과 덧셈을 모두 수행합니다.

이러한 함수에 다른 이름을 지정하면 mul!(C,A,B) = dgemm(C,A,B,1,0) 및 muladd!(C,A,B,α, β) = dgemm(C,A,B,α, β) 됩니다.

내가 보는 유일한 장점은 실제로 메서드를 분할하고 C = A*B 케이스에서 if β==0 호출을 저장하는 것입니다.

참고로, 나는 인터페이스를 matmul.jl 에 추가하기 위해 # 29634에서 작업을 시작했습니다. 이름과 서명이 결정될 때까지 끝내고 싶습니다 :)

muladd! 의 장점은 기본 α = β = true (원래 제안 https에서 언급 한대로)로 삼항 muladd!(A, B, C) (또는 muladd!(C, A, B) ?)를 가질 수 있다는 것입니다. //github.com/JuliaLang/julia/issues/23919#issuecomment-402953987). 방법 muladd!(A, B, C) 비슷합니다 muladd 에 대해 Number 나는 당신이 이미 알고있는 경우 특히 더 자연스러운 이름을 추측 있도록이야 muladd .

@andreasnoack 이전 논의는 메소드 서명에 대한 것이며 메소드 이름이 아니라 키워드 인수보다 위치 인수를 선호하는 것 같습니다. muladd! 라는 이름에 대해 이의가 있습니까? ( SparseArrays 에 5-ary mul! 의 존재는 하나 일 수 있지만 이전 버전과 호환되는 래퍼를 정의하는 것은 어렵지 않습니다.)

mul! 및 muladd! α 및 β 기본값을 사용하여 전자가 후자 일 때 중복 된 것처럼 보입니다. 또한 add 부분은 BLAS에 의해 표준화되었습니다. muladd! 대한 신뢰할 수있는 일반 선형 대수 응용 프로그램을 생각해 낼 수 있다면 그것에 대해 듣고 싶지만 그렇지 않으면 중복을 피하고 싶습니다.

또한 mul! 의 논의와 별도로 false 의 strong-zero 속성을 유지하는 것이 좋습니다. IMO β의 0 값은 BLAS에서와 같이 현재 5 개의 인수 mul! 메서드 에서처럼 강력해야합니다. 즉,이 동작은 β 유형이 아니라 mul! 의 결과 여야합니다. 대안은 함께 작동하기 어려울 것입니다. 예 : mul!(Matrix{Float64}, Matrix{Float64}, Matrix{Float64}, 1.0, 0.0) ~ could ~ BLAS를 사용할 수 없습니다.

BLAS가 수행하는 작업을 변경할 수는 없지만 float에 대한 _requiring_ 강력한 제로 동작은 모든 구현에 0을 확인하기 위해 분기가 필요함을 의미합니다.

muladd! 대한 신뢰할 수있는 일반 선형 대수 응용 프로그램을 만들 수 있다면

이것에 의하여 @andreasnoack, 나는 당신이 "에 대한 응용 프로그램 _three을-argument_ 의미 가정 muladd! "그렇지 않으면 당신은 다섯 인수 포함 동의하지 않을 것이기 때문에 mul! ?

하지만 여전히 muladd!(A, B, C) 가 유용한 예를 생각해 낼 수 있습니다. 예를 들어 "작은 세계"네트워크를 구성하려는 경우 띠 행렬과 희소 행렬의 "지연"합계를 사용하는 것이 유용합니다. 그런 다음 다음과 같이 작성할 수 있습니다.

A :: SparseMatrixCSC
B :: BandedMatrix
x :: Vector  # input
y :: Vector  # output

# Compute `y .= (A .+ B) * x` efficiently:
fill!(y, 0)
muladd!(x, A, y)  # y .+= A * x
muladd!(x, B, y)  # y .+= B * x

그러나 나는 단순히 내 사용을 위해 그것을 감쌀 수 있기 때문에 거기에 true s를 수동으로 쓰는 것을 신경 쓰지 않습니다. 5 개 인수 함수를 안정적인 문서화 된 API로 갖는 것이 여기서 가장 중요한 목표입니다.

요점으로 돌아 가기 :

mul! 및 muladd! α 및 β 기본값을 사용하여 전자가 후자 일 때 중복 된 것처럼 보입니다.

그러나 출력 배열의 "기본값"이 적절하게 초기화 된 mul! 측면에서 * 구현되었습니다. Base 및 표준 라이브러리에 이러한 "바로 가기"예제가있을 수 있다고 생각합니다. mul! 이 muladd! 의 바로 가기 일지라도 mul! 와 muladd! 을 모두 갖는 것이 합리적이라고 생각합니다.

난 강력하게 우리의 강한 제로 속성을 유지하는 것이 원합니다 false 논의 별도로 mul!

먼저 곱하기-더하기의 5 개 인수 버전의 이름을 논의하는 데 집중하는 것이 건설적이라는 데 동의합니다 ( mul! 대 muladd! ).

행렬과 숫자에서 일반적으로 작업하기 위해 muladd 이 필요한 일반적인 사용 사례를 요청했을 때 저는 잘하지 못했습니다. 숫자 버전은 느낌표가없는 muladd 이므로 제가 요청한 내용이 의미가 없습니다.

귀하의 예는 다음과 같이 작성할 수 있습니다.

mul!(y, A, x, 1, 1)
mul!(y, B, x, 1, 1)

그래서 나는 여전히 muladd! 의 필요성을 보지 못합니다. 이 경우가 너무 흔해서 1, 1 를 쓰는 것이 너무 장황하다고 생각하십니까?

그러나 출력 배열의 "기본값"이 적절하게 초기화 된 mul! 측면에서 * 구현되었습니다. Base 및 표준 라이브러리에 이러한 "바로 가기"예제가있을 수 있다고 생각합니다.

나는 이것을 얻지 못한다. 자세히 설명해 주시겠습니까? 여기서 말하는 지름길은 무엇입니까?

그래서 나는 여전히 muladd! 의 필요성을 보지 못합니다. 이 경우가 너무 흔해서 1, 1 것이 너무 장황하다고 생각하십니까?

나는 muladd! 또한 그것이 실제로 무엇을하는지에 대해 더 설명 적이라고 생각합니다 (아마도 addmul! 여야합니다).

이름 muladd! 에는 문제가 없습니다. 우선, 저는 우리가 이것을 위해 기능을해야한다고 생각하지 않으며, 이차적으로 muladd! / addmul! 대신 mul! 를 비추천하는 것은 그만한 가치가 없다고 생각합니다.

이 경우가 너무 흔해서 1, 1을 쓰는 것이 너무 장황하다고 생각하는 것입니까?

아니요. 공용 API 인 한 5 개의 인수 함수를 호출해도 괜찮습니다. 나는 단지 세 가지 인수 버전이 필요한 경우의 예를 제공하려고했습니다 (당신의 요청이라고 생각했습니다).

여기서 말하는 지름길은 무엇입니까?

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAlgebra/src/matmul.jl#L140 -L143

여기에 정의 된 * 는 mul! 의 바로 가기로 간주 될 수 있다고 생각합니다. 기본값은 "단지" mul! 입니다. 그렇다면 mul! addmul! 를 기본값으로 muladd! / addmul! 로 두지 않는 이유는 무엇입니까?

유사한 "바로 가기"로 정의 된 rmul! 및 lmul! 도 있습니다.

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAlgebra/src/triangular.jl#L478 -L479

mul! 지원 중단

나는 토론이 새로운 인터페이스 추가에 관한 것이라고 생각했습니다. 새 API를 추가하기 위해 mul! 를 지원 중단해야한다면 그만한 가치가 없다고 생각합니다.

제가 생각할 수있는 주요 주장은 다음과 같습니다.

• 개념적으로 5- 인수 형식은 단순히 "곱하기"이상을 수행하며이를 더 명확하게 전달합니다.
• 그런 다음 mul!(C,A,B,1,1) 또는 mul!(C,A,B,true,true) 대신 addmul!(C, A, B) 를 쓸 수 있습니다.

여기에 정의 된 * 는 mul! 의 바로 가기로 간주 될 수 있다고 생각합니다. 기본값은 "단지" mul! 입니다. 그래서, 왜 멀을 두지 마십시오! 기본값이있는 muladd! / addmul! 입니까?

* 는 행렬을 곱하는 기본 방법이며 대부분의 사용자가 수행하는 방법이기 때문입니다. 이에 비해 muladd! 는 사용량이 * 에 가깝지 않습니다. 또한 기존 연산자 인 반면 muladd! / addmul! 는 새 함수입니다.

rmul! 및 lmul! 은 일반적으로 out-of-place mul! 메서드의 기본값 버전이 아니기 때문에이 패턴에 적합하다고 생각하지 마십시오.

Simon은 위의 게시물에서 이점을 멋지게 요약합니다. 문제는 이름 변경의 추가 기능 ( mul! 지원 중단을 의미 함)을 정당화 할만큼 이점이 충분히 큰지 여부입니다. 우리가 동의하지 않는 곳입니다. 그만한 가치가 없다고 생각합니다.

이름 변경이 그만한 가치가 없다고 말할 때 API가 완전히 공개되지 않는다는 점을 고려 했습니까? 그것은 Julia의 문서에 없다는 것을 의미합니다.

나는 LazyArrays.jl (및 다른 패키지?)이 이미 그것을 사용하고 있으므로 맹목적으로 semver를 따르는 것은 좋지 않을 것입니다. 그러나 여전히 다른 기능만큼 공개되지는 않습니다.

mul! 는 LinearAlgebra 에서 내보내지고 광범위하게 사용되므로이 시점에서 사용을 중단해야합니다. A_mul_B! 가 mul! 가되었을 때 또는 적어도 0.7 이전에이 토론을하지 않은 것은 부끄러운 일입니다. 함수 이름을 바꾸는 것이 훨씬 더 좋은시기 였기 때문입니다.

지금은 mul! 를 사용하고 stdlibs를 별도로 업데이트 할 수있을 때 LinearAlgebra v2.0 의 이름을 업데이트하는 것은 어떻습니까?

LazyArrays.jl은 많은 유형의 행렬에 대해 유연하지 않기 때문에 mul! 사용하지 않습니다 (그리고 StridedArray s로 재정의 할 때 컴파일러 속도 저하 버그를 유발 함). 양식의 대체 구성을 제공합니다.

y .= Mul(A, x)

내가 찾은 것이 더 설명 적입니다. 5 가지 인수 아날로그는 다음과 같습니다.

y .= a .* Mul(A, x) .+ b .* y

나는 mul! 를 비추천하고 LinearAlgebra.jl에서 LazyArrays.jl 접근 방식으로 이동하는 것을 찬성 하겠지만, 그것은 어려운 경우가 될 것입니다.

LowRankApprox.jl은 mul! 를 사용하지만 LazyArrays.jl 접근 방식을 사용하도록 변경하여 컴파일러 버그를 피할 수 있습니다.

확인. 저는 제안이 두 개 밖에 없다고 생각했습니다. 그러나 분명히 대략 세 가지 제안이 있습니까? :

1. 3 인수 및 5 인수 mul!
2. 3 인수 및 5 인수 muladd!
3. 3 인수 mul! 및 5 인수 muladd!

( muladd! 는 addmul! 라고도 함)

나는 우리가 1과 3을 비교하고 있다고 생각하고 있었다. 이제 내 이해는 @andreasnoack 이 1과 2를 비교하고 있다는

3 인수 mul! 는 공용 API이고 널리 사용되기 때문에 2는 전혀 옵션이 아닙니다. "API가 완전히 공개되지 않는다"는 의미는 5 개 인수 mul! 가 문서화되어 있지 않다는 것 입니다.

예, 내 계획은 mul! (3 arg 및 가능하면 4 arg 형식)을 유지하는 것이 었습니다. 3 arg mul! 및 addmul! 이 다른 동작을 가질 것이기 때문에 이것이 가치가 있다고 생각합니다. 즉, addmul!(C, A, B, α, β) 주어지면 다음과 같이됩니다.

mul!(C, A, B) = addmul!(C, A, B, 1, 0)
mul!(C, A, B, α) = addmul!(C, A, B, α, 0)
addmul!(C, A, B) = addmul!(C, A, B, 1, 1)
addmul!(C, A, B, α) = addmul!(C, A, B, α, 1)

그러나 실제로 이러한 방식으로 구현하고 싶지 않을 수 있습니다. 예를 들어 4 인수 mul! 및 addmul! 따로 분리하고 5 인수 addmul! 정의하는 것이 더 간단 할 수 있습니다.

addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

충돌!

그러나 실제로 이런 방식으로 구현하고 싶지 않을 수도 있습니다. 예를 들어 4-arg mul! 그리고 addmul! 별도로 정의하고 5-arg addmul! 같이:
addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

바로 최적으로 수행하지 않는 이유는 무엇입니까? 그렇게하지 않는 요점은 C 의 요소를 한 번만 방문하면되므로 큰 행렬의 경우 확실히 더 효율적입니다. 또한 5-arg addmul! 와 4-arg mul! 및 addmul! 별도로 정의하면 코드가 더 길어질 것이라고 믿을 수 없습니다.

참고로 저는 LinearAlgebra의 _generic_matmatmul! 구현을 수정하여 LazyArrays에서 5 개의 인수를 취했습니다 : https://github.com/JuliaArrays/LazyArrays.jl/blob/8a50250fc6cf3f2402758088227769cf2de2e053/src/linalg/blasmul.jl#L70

다음을 통해 호출됩니다.

materialize!(MulAdd(α, A, b, β, c)) 

그러나 실제 코드 ( tiled_blasmul! )는 LinearAlgebra로 다시 번역하기 쉽습니다.

이 프로세스의 속도를 높이기 위해 무엇을 할 수 있습니까? 내가 작업중인 것들은 in-place mul + add가있는 통합 행렬 곱셈 API의 이점을 얻을 것입니다.

Strided.jl 의 최신 버전은 이제 5 개의 인수 mul!(C,A,B,α,β) 하고 가능하면 BLAS로 디스패치하고 그렇지 않으면 자체 (다중 스레드) 구현을 사용합니다.

@Jutho 훌륭한 패키지! 다음 단계에 대한 로드맵이 있습니까? 계획이 결국 LinearAlgebra와 병합 될 수 있을까요?

이것은 내 의도가 아니었지만 어느 시점에서 요청이된다면 반대하지 않습니다. 그러나 일반적인 mapreduce 기능에서 @generated 함수 (하나만 있음)를 자유롭게 사용하면 Base에 적합하지 않을 수 있습니다.

내 개인 로드맵 : 이것은 주로 상위 수준 패키지, 즉 새로운 버전의 TensorOperations 및 내가 작업중인 다른 패키지에서 사용되는 하위 수준 패키지입니다. 그러나 기본 선형 대수에 대한 더 많은 지원이 좋을 것입니다 (예 : norm 에 StridedView 현재 Julia Base에서 norm 의 다소 느린 구현으로 돌아갑니다). 나는 시간이와 GPU를 작업에 배울 수 있다면, 동등하게 일반적인 구현하려고 mapreducekernel 에 대해 GPUArray 들.

지금까지 합의 된 내용은 다음과 같습니다.

1. mul!(C, A, B) 유지해야합니다
2. inplace multiply-add C = αAB + βC 위해 _some_ 5-argument 함수가 필요합니다.

먼저 5- 인수 함수의 이름에 초점을 맞추고 나중에 추가 API에 대해 논의 할 것을 제안합니다 (예 : 3- 및 4- 인수 addmul! ). 그러나 이것은 우리가 mul! 를 사용하여 _not_에서 얻은 "기능"이므로 혼합하지 않기가 어렵습니다.

@andreasnoack 사용 중단 / 이름 변경에 대한 우려 사항은 위의 @simonbyrne 의 의견으로 해결 되었습니까? https://github.com/JuliaLang/julia/issues/23919#issuecomment -431046516? 지원 중단이 필요 없다고 생각합니다.

참고로, 방금 구현 # 29634를 완료했습니다. LinearAlgebra 익숙한 사람이 검토해 주시면 감사하겠습니다.

모든 이름을 mul! 것이 더 간단하고 낫다고 생각합니다. 또한 지원 중단을 방지합니다. 정말로 다른 이름을 원하면 muladd 가 더 좋습니다.

mul! API를 논의 할 때 고려해야 할 다른 사항 :

scale! 가 사라지고 0.6-> 0.7 전환에 흡수되었을 때, 저는 조금 슬펐습니다. 왜냐하면 저에게 스칼라 곱셈 (벡터 공간의 속성)이 객체를 곱하는 것과는 매우 달랐기 때문입니다 (대수의 속성). ). 그럼에도 불구하고 저는 mul! 접근 방식을 완전히 수용했으며 스칼라 곱셈이 교환 적이 지 않을 때 rmul!(vector,scalar) 및 lmul!(scalar,vector) 기능을 매우 높이 평가합니다. 하지만 지금은 다른 두 개의 in place 벡터 공간 연산 인 axpy! 및 일반화 axpby! 의 un-Julian 이름에 매일 더 신경을 씁니다. 이것도 mul! / muladd! / addmul! 흡수 될 수 있습니까? 약간 이상하지만 A*B 의 두 요소 중 하나가 이미 스칼라이면 추가 스칼라 요소 α 가 필요하지 않습니다.
그러나 아마도 다음과 유사하게

mul!(C, A, B, α, β)

또한있을 수 있습니다

add!(Y, X, α, β)

axpby! 를 대체합니다.

@andreasnoack 사용 중단 / 이름 변경에 대한 우려 사항이 # 23919 (코멘트) 위의 @simonbyrne 의 의견으로 해결 되었습니까? 지원 중단이 필요 없다고 생각합니다.

https://github.com/JuliaLang/julia/issues/23919#issuecomment -430952179의 마지막 단락을 mul! 폐기해야한다고 생각합니다.

내가 이름을 바꾸는 생각 @Jutho acp(b)y! 에 add! 좋은 아이디어가 될 것입니다.

# 23919 (코멘트) 의 마지막 단락을 참조하십시오. 나는 여전히 새로운 기능을 도입하는 것이 그만한 가치가 없다고 생각합니다.

예, 저는 그것을 읽고 5 개 인수 mul! 가 문서화되지 않았으며 공개 API의 일부가 아니라고 답했습니다. 따라서 _ 기술적으로 _ 지원 중단이 필요하지 않습니다. https://github.com/JuliaLang/julia/issues/23919#issuecomment -430975159의 마지막 단락을

여기서는 하나의 서명 (예 : mul!(C, A, B) )의 문서화로 인한 공개 API 선언이 다른 서명 (예 : mul!(C, A, B, α, β) )에 적용되지 않는다고 가정합니다. 그것이 사실이 아니라면 Julia와 stdlib가 너무 많은 내부를 노출하고 있다고 생각합니다. 예를 들어, 다음은 Pkg.add 의 문서화 된 서명입니다.

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/Pkg.jl#L76 -L79

실제 정의는

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/API.jl#L69 -L70

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/src/API.jl#L27 -L33

Pkg.add 서명이 하나 이상 존재한다는 것이 다른 서명이 공용 API임을 의미하는 경우 Pkg.jl은 주요 버전을 충돌하지 않고 구현 세부 사항으로 인해 동작을 제거 할 수 없습니다 (예 : Pkg.add(...; mode = :develop) 실행 Pkg.develop(...) ; Context! 대한 모든 키워드 인수가 지원됩니다 (실제로 의도되었을 수 있음).

그러나 이것은 어쨌든 내 인상입니다. mul!(C, A, B, α, β) 이 mul!(C, A, B) 만큼 공개되었다고 생각하십니까?

나는 우리가 서로 과거에 이야기하고 있다고 생각합니다. 내가 말하는 것은 (여전히) 다른 기능을 도입하는 것이 그만한 가치가 없다고 생각한다는 것입니다. 따라서 이전 의견에 대한 참조. 이는 5 개 인수 mul! 의 지원 중단에 대한 논의와는 별개입니다.

우리가 다음 다른 기능을 추가하기로 결정한다면, 나는 그것이 오 논쟁을 지양하기 위해 최선을 다 할 것이라고 생각 mul! 대신에 그냥 파괴. 물론, 3 인수 mul! 만큼 일반적으로 사용되지는 않지만, 그냥 깨뜨리는 대신 비추천하지 않는 이유는 무엇입니까?

이는 5 개 인수 mul! 의 지원 중단에 대한 논의와는 별개입니다.

귀하의 코멘트의 마지막 단락의 나의 해석 https://github.com/JuliaLang/julia/issues/23919#issuecomment가 -430952179 당신이 혜택을 나열 @simonbyrne 인정이었다 https://github.com/JuliaLang/julia/issues / 23919 # issuecomment -430809383은 새로운 5 개 인수 함수에 대해 _public API_를 유지하는 것에 비해 가치가 낮다고 생각했습니다 ( "이름 변경"및 "지원 중단"에서 언급했듯이). 그래서 저는 5 개 인수 mul! 가 공개되었는지 여부를 고려하는 것이 중요하다고 생각했습니다.

그러나 당신은 또한 당신이 지금 언급하고있는 "추가 기능"을 갖는 것에 대한 정당성을 언급했습니다. 계산 _C = AB_ 및 _C = αAB + βC_가 충분히 유사하여 동일한 이름이 둘 다를 설명 할 수 있다고 주장합니까? 3 개 인수 mul! 를 일반화하는 다른 방법이있을 수 있으므로 실제로 동의하지 않습니다. 예를 들어 _y = A₁ A₂ ⋯ Aₙ x_ https://github.com/JuliaLang/julia에 대해 mul!(y, A₁, A₂, ..., Aₙ, x) / issues / 23919 # issuecomment -402953987?

왜 그것을 깨뜨리는 대신 비난하지 않습니까?

이전 의견에서 말했듯이, 5 개 인수 mul! 를 사용하지 않는 것이 _if_ 다른 함수를 도입하는 것이 옳다는 데 동의합니다. 이 코드는 이미 내 PR # 29634에 있습니다.

계산 C = AB 및 C = αAB + βC가 충분히 유사하여 동일한 이름이 둘 다를 설명 할 수 있다고 주장합니까?

예, 전자는 β=0 와 함께 후자이기 때문입니다. muladd! / addmul! 가 C = αAB + βC 대한 더 정확한 이름이라고 주장하는 것이 타당하지만 거기에 도달하려면 다른 행렬 곱셈 함수를 도입해야합니다 ( muladd! / addmul! ) 또는 mul! 이름을 바꾸고 지금은 그럴 가치가 없다고 생각합니다. 이것이 봄에 나온다면 변화를 고려하는 것이 더 쉬웠을 것입니다.

3 인수 mul을 일반화하는 다른 방법이있을 수 있기 때문에 실제로 동의하지 않습니다! :

Julia는 α 및 β 인수없이 in-place matrix multiply 메서드를 정의했지만 행렬 곱셈 전통은 실제로 BLAS-3을 기반으로하며 일반적인 행렬 곱셈 함수는 C = αAB + βC .

mul! 이름 바꾸기

stdlib 또는 다운 스트림 사용자 모듈 / 코드에서 이름을 바꾸는 것을 의미합니까? 전자를 의미한다면, 이미 # 29634에서 (LinearAlgebra 및 SparseArrays의 경우) 완료되었으므로 걱정할 필요가 없다고 생각합니다. 후자를 의미한다면, 다시 한 번 공개 토론이 아닌 토론으로 귀결된다고 생각합니다.

행렬 곱셈 전통은 실제로 BLAS-3을 기반으로합니다.

그러나 Julia는 이미 BLAS의 명명 규칙을 벗어났습니다. 더 설명적인 이름을 갖는 것이 좋지 않을까요?

stdlib 또는 다운 스트림 사용자 모듈 / 코드에서 이름을 바꾸는 것을 의미합니까?

29634는 mul! 함수의 이름을 바꾸지 않습니다. 새로운 함수 addmul! 합니다.

그러나 Julia는 이미 BLAS의 명명 규칙을 벗어났습니다.

명명에 대해 말하는 것이 아닙니다. 적어도 Fortran 77에는 함수 이름과 디스패치 측면에서 둘 다 가지고 있지 않은 몇 가지 제한이 있기 때문에 정확히는 아닙니다. 나는 계산되는 것에 대해 이야기하고 있습니다. BLAS-3의 일반 행렬 곱셈 함수는 C = αAB + βC 계산하고 Julia에서는 mul! (fka A_mul_B! )입니다.

더 설명적인 이름을 갖는 것이 좋지 않을까요?

그럴 것입니다. 나는 여러 번 말했습니다. 문제는 기본적으로 동일한 작업을 수행하는 두 개의 행렬 곱셈 함수를 가져야하는 것이 그리 좋지 않다는 것입니다.

29634는 mul! 함수의 이름을 바꾸지 않습니다. 새로운 함수 addmul! 합니다.

제가 말하고자하는 것은 5 개 인수 mul! 가 addmul! 로 이름이 바뀌 었다는 것입니다.

문제는 기본적으로 동일한 작업을 수행하는 두 개의 행렬 곱셈 함수를 가져야하는 것이 그리 좋지 않다는 것입니다.

기본적으로 같은지 아닌지는 다소 주관적이라고 생각합니다. 나는 _C = αAB + βC_와 _Y = A₁ A₂ ⋯ Aₙ X_ 모두 _C = AB_의 수학적으로 유효한 일반화라고 생각합니다. _C = αAB + βC_가 고유 한 일반화가 아니라면이 주장이 충분히 강하다고 생각하지 않습니다. 또한 BLAS API를 알고 있는지 여부에 따라 다르며 이것이 일반적인 Julia 사용자를위한 기본 지식인지 확실하지 않습니다.

또한 _C = AB_ 및 _C = αAB + βC_는 C 이 사용되는지 여부가 계산 상 매우 다릅니다. 전자의 경우 출력 전용 매개 변수이고 후자의 경우 입력-출력 매개 변수입니다. 이 차이는 시각적 인 단서를받을 만하다고 생각합니다. mul!(some_func(...), ...) 에 mul! 에 5 개의 인수 형식이있는 경우 인수의 수를 계산해야합니다 (괄호를 일치시켜야하므로 함수 호출의 결과 인 경우 어렵습니다). some_func 가 계산을 수행하는지 아니면 할당 만 수행하는지 확인합니다. 우리가있는 경우 addmul! 다음 나는 즉시 그 기대할 수 some_func 에서 mul!(some_func(...), ...) 만 수행 할당.

기본적으로 같은지 아닌지는 다소 주관적이라고 생각합니다. 나는 C = αAB + βC와 Y = A₁ A₂ ⋯ Aₙ X 둘 다 수학적으로 유효한 C = AB의 일반화라고 생각합니다. C = αAB + βC가 고유 한 일반화가 아니라면이 주장이 충분히 강하다고 생각하지 않습니다.

고유 한 일반화가 아닐 수도 있지만 대략 동일한 비용으로 계산할 수있는 일반화이며 다른 선형 대수 알고리즘을 구축하는 데 유용한 기본 요소를 형성합니다. 많은 경우에 다양한 선형 대수 관련 알고리즘을 구현할 때 0이 아닌 베타를 갖고 싶었고 항상 BLAS.gemm! 돌아 가야했습니다. 언급 한 것과 같은 다른 일반화는 중간 임시없이 한 번에 계산할 수 없으므로 내부 버전은 훨씬 덜 유용합니다. 또한 일반적으로 기본 작업만큼 유용하지 않습니다.

또한 BLAS API를 알고 있는지 여부에 따라 다르며 이것이 일반적인 Julia 사용자를위한 기본 지식인지 확실하지 않습니다.

기본 인수 α=1 및 β=0 가 여전히 제자리에있는 한, 세 개의 인수 mul! 는 Julia 사용자가 BLAS 배경없이 합리적으로 기대할 수있는 작업을 수행합니다. 고급 옵션의 경우 모든 언어 및 기능과 관련이 있으므로 설명서를 참조해야합니다. 또한,이 단일 mul! 호출은 gemm 뿐만 아니라 gemv 및 trmv (이상하게도 α 및 BLAS API의 β 매개 변수) 및 기타 여러 매개 변수.

나는 BLAS-3이 계산 측면에서 올바른 일반화라는 데 동의하며 매우 잘 구성됩니다. 동일한 이름을 사용하는 것이 "충분히 고유하지 않다"고 생각하기 때문에 가능한 또 다른 일반화를 제시하고 있습니다. https://github.com/JuliaLang/julia/issues/23919#issuecomment -441267056의 마지막 단락에서 출력 전용 대 입력-출력 인수도

또한이 단일 mul! 호출은 gemm 뿐만 아니라 gemv 및 trmv (이상하게도 α 및 BLAS API의 β 매개 변수) 및 기타 여러 매개 변수.

네, 이미 # 29634에서 구현되었으며 이름이 결정되고 검토를 받으면 바로 사용할 수 있습니다!

이 대화를 따라가는 데 어려움을 겪고 있습니다 (약간 길고 넓어집니다 ... 죄송합니다!). 주요 제안이 mul!(C, A, B; α=true, β=false) 와 (과) 같은 것입니까?

나는 α와 β에 대한 키워드 인수가 테이블에 있다고 생각하지 않습니다. 예를 들어 @andreasnoack 은 https://github.com/JuliaLang/julia/issues/23919#issuecomment -365762889에서 키워드 인수를 무시했습니다. @simonbyrne 은 https://github.com/JuliaLang/julia/issues/23919#issuecomment -426881998에서 키워드 인수를 언급했지만 그의 최근 제안은 https://github.com/JuliaLang/julia/issues/23919#issuecomment -431046516입니다. 인수.

우리는 아직 이름을 정하지 않았고 (즉, mul! vs addmul! vs muladd! ) 이것이 핵심 주제라고 생각합니다 (또는 적어도 그것이 내 소원입니다).

이런 종류의 논쟁을 일반적으로 어떻게 해결합니까? 투표? 분류?

주요 제안은 mul! (C, A, B; α = true, β = false)과 같은 것입니까?

나는 이것을 좋아하지만 kwargs가 없습니다.

키워드 물건을 보지 못했습니다. 유니 코드 키워드를 추가하는 것도 주저합니다. 이러한 기본값을 가진 위치 인수는 괜찮다고 생각합니다. 다가오는 투표는 mul! 입니다. 나는 이것이 새로운 이름이 필요하지 않을 정도로 충분히 구체적이고 유용한 mul! 의 일반화라고 생각합니다.

(적어도 지금은) 데이터를 수집하기 위해 투표를합시다.

_C = αAB + βC_에서 가장 좋아하는 함수 이름은 무엇입니까?

• : +1 : mul!
• : -1 : addmul!
• : 미소 : muladd!
• : tada : 다른 것

나에게 addmul! 설명하는 것 (A+B)C 대신 AB + C .

처음에 저는 mul! 투표 한 다음 연산을보고 "곱하기를 한 다음 더하기를 수행하고 있습니다. 당연히 muladd! 라고 불러야합니다. 이제 호출 할 생각이 없습니다. 그것이 제자리에 있다는 사실은 ! 로 명확하게 표시되고 스케일링 부분은 키워드 인수에 적합 해 보입니다.

곱하기와 더하기를하고 있습니다. 당연히 muladd! 라고 불러야합니다.

기본값 β=true 를 사용하는 경우에만 다른 값에 대해서는 다시 더 일반적인 값입니다. 그래서 그것을 mul! 라고 부르지 않는 이유는 무엇입니까? 다른 값은 기본값 β=false 도 당신에게 더 일반적인 것을 제공합니다. 그리고 muladd(x,y,z) = x*y + z 와 비교하여 인수를 어떻게 정렬 하시겠습니까? 다소 혼란스럽지 않습니까?

내 생각 muladd! 라는 설명은 같은 것이다 : 그렇지 않은 경우 설명을 소리의 단점이있다 scalemuladd! 스케일링 부분을 언급.

그래서 저는 mul! 를 선호합니다. 그것은 기대치로 이어지지 않을만큼 충분히 설명 적이 지 않기 때문입니다.

즉, LazyArrays.jl MulAdd 에서 lazy 버전을 호출합니다.

C ( mul! )의 값을 사용하지 않는 함수를 사용하는 함수와 구별하는 것이 좋기 때문에 muladd! mul! 선호합니다. ( muladd! ).

• 기술적으로는 행렬 곱셈입니다. [AC] * [Bα; Iβ] 또는 아래 주석 참조 [αA βC] * [B; 나는]
• ~ 우리는 희소 행렬에 대해 이미 5-arg mul! 를 가지고 있습니다. 조밀 한 linalg에 대해서도 동일합니다. (새로운 인수가 아님)

그래서 나는 그것을 mul! 라고 부르는 편이 낫습니다.

• 기술적으로 이것은 행렬 곱셈입니다. [AC] * [Bα; Iβ]

... eltype에 교환 곱셈이있는 경우

... eltype이 교환 형인 경우.

@andreasnoack Julia와의 토론에서 나온 IIRC는 gemm / gemv 를 y <- A * x * α + y * β 합니다.

@haampie 잘 알고 있습니다! # 29634에서 다른 방식으로 구현했습니다.

이것은 도움이 제한적이지만

       C = α*A*B + β*C

작업을 표현할 수있는 가장 좋은 방법이므로 매크로 <strong i="8">@call</strong> C = α*A*B + β*C 또는 <strong i="10">@call_specialized</strong> ... 또는 이러한 라인을 따라있는 것이 자연스러운 인터페이스가 될 수 있습니다. 유사한 상황에서도 마찬가지입니다. 그런 다음 기본 함수를 무엇이든 호출 할 수 있습니다.

@dlfivefifty의 @mschauer LazyArrays.jl 은 구문과 같이 5 인수 mul! 를 호출하는 훌륭한 구문을 가지고 있습니다.

먼저 함수 기반 API를 설정하고 패키지 작성자가 특수 행렬에 대해 오버로드를 시작할 수 있도록해야한다고 생각합니다. 그런 다음 Julia 커뮤니티는이를 호출하기 위해 설탕을 실험 할 수 있습니다.

기본값 β=true 을 사용하는 경우에만 다른 값에 대해서는 다시 더 일반적인 값입니다. 그래서 그것을 mul! 라고 부르지 않는 이유는 무엇입니까? 다른 값은 기본값 β=false 도 더 일반적인 것을 제공합니다. 그리고 muladd(x,y,z) = x*y + z 와 비교하여 인수를 어떻게 정렬 하시겠습니까? 다소 혼란스럽지 않습니까?

확실히 거기에 약간의 스케일링이 있지만 작업의 "본"은 분명히 곱하고 더합니다. muladd 의 서명과 일치하도록 muladd!(A, B, C, α=true, β=false) 으로도 괜찮습니다. 물론 문서화되어야하지만 그것은 말할 필요도 없습니다. muladd 가 첨가물 부분을 먼저 가져 갔으면 좋겠지 만 배는 그 부분을 타고 항해했습니다.

그리고 muladd(x,y,z) = x*y + z 와 비교하여 인수를 어떻게 정렬 하시겠습니까? 다소 혼란스럽지 않습니까?

이것이 제가 addmul! 보다 muladd! addmul! 를 선호하는 이유입니다. 인수의 순서가 스칼라 muladd 와 관련이 없는지 확인할 수 있습니다. ( muladd! 보다 mul! muladd! 를 선호하지만)

여기 FWIW는 지금까지의 주장을 요약 한 것입니다. (나는 중립적으로 노력했지만 나는 프로 다- muladd! / addmul! 그래서 명심해라 ...)

주된 의견 차이는 _C = AB_ 및 _C = αAB + βC_가 후자에 대해 새 이름을 부여 할만큼 충분히 다른지 여부입니다.

그들은 충분히 유사합니다.

1. BLAS-3이며 멋지게 구성 할 수 있습니다. 따라서 _C = αAB + βC_는 _C = AB_의 명백한 일반화입니다 (https://github.com/JuliaLang/julia/issues/23919#issuecomment-441246606, https://github.com/JuliaLang/julia/issues/ 23919 # issuecomment-441312375 등)

2. _ " muladd! 에는 그렇지 않은 경우 설명 적으로 들리는 단점이 있습니다. 설명 적 이름은 스케일링 부분을 언급하기 위해 scalemuladd! 와 같은 것입니다."_ --- https://github.com/ JuliaLang / julia / issues / 23919 # issuecomment -441819470

3. _ "기술적으로는 행렬 곱셈입니다. [AC] * [Bα; Iβ]"_ --- https://github.com/JuliaLang/julia/issues/23919#issuecomment -441825009

그들은 충분히 다른 이유는 ...

1. _C = αAB + βC_는 곱하기 그 이상입니다 (https://github.com/JuliaLang/julia/issues/23919#issuecomment-430809383, https://github.com/JuliaLang/julia/issues/23919#issuecomment-427075792, https://github.com/JuliaLang/julia/issues/23919#issuecomment-441813176 등).

2. Y = A₁ A₂ ⋯ Aₙ X (https://github.com/JuliaLang/julia/issues/23919#issuecomment-402953987 등)과 같은 mul! 의 다른 일반화가있을 수 있습니다.

3. 입력 전용 vs 입력-출력 매개 변수 : 인수 수에 따라 C 의 데이터를 사용하는 함수를 사용하는 것은 혼란 스럽습니다 (https://github.com/JuliaLang/julia/issues/23919#issuecomment -441267056, https://github.com/JuliaLang/julia/issues/23919#issuecomment-441824982)

mul! 이 더 좋은 또 다른 이유는 ... :

1. 희소 행렬에는 이미 있습니다. 따라서 이전 버전과의 호환성에 좋습니다. 반대 인수 : 5 개 인수 mul! 는 문서화 되어 있지 않으므로 공용 API로 간주 할 필요가 없습니다.

그리고 왜 muladd! / addmul! 이 더 좋은 이유는 ... :

1. mul! 및 muladd! / addmul! 대해 서로 다른 3 개 또는 4 개 인수 "핸디 함수"를 개별적으로 가질 수 있습니다 (https://github.com/JuliaLang/julia/issues / 23919 # issuecomment-402953987, https://github.com/JuliaLang/julia/issues/23919#issuecomment-431046516 등). 반대 주장 : mul!(y, A, x, 1, 1) 쓰는 것은 mul!(y, A, x) (https://github.com/JuliaLang/julia/issues/23919#issuecomment-430674934 등)에 비해 그다지 장황하지 않습니다.

객관적인 요약 @tkf에 감사드립니다.

muladd의 서명과 일치시키기 위해 muladd! (A, B, C, α = true, β = false)로도 괜찮습니다.

mulladd! 라는 함수의 경우 기본값이 β=true 이길 바랍니다. 그래도 muladd 에서 지시되는이 인수 순서는 mul!(C,A,B) 과 관련하여 매우 혼란 스러울 것입니다.

내가 착각했을 수도 있지만, 대부분의 사람 / 응용 프로그램 / 고수준 코드 (이미 곱셈 연산자 * 만으로 만족스럽지 않음)에는 mul! 가 필요하다고 생각합니다. βC 를 β=1 ( true ) 또는 다른 방법과 혼합하는 기능은 행렬 곱셈을위한 BLAS API가 가능하다는 것을 아는 사람들에 의해 하위 수준 코드에서 사용됩니다. 이. 나는이 사람들이 gemm , gemv 대한 Julia 인터페이스 인 mul! 아래에서이 기능을 찾을 것이라고 생각합니다. ... 새 이름 추가 (혼란스러운 반대 인수 순서) 그만한 가치가없는 것 같습니다. 나는 이득을 보지 못합니까?

나는이 사람들이 gemm , gemv 대한 Julia 인터페이스 인 mul! 아래에서이 기능을 찾을 것이라고 생각합니다. ... 새 이름 추가 (혼란스러운 반대 인수 순서) 그만한 가치가없는 것 같습니다. 나는 이득을 보지 못합니까?

mul! 독 스트링에서 muladd! 를 간단히 언급 할 수 있기 때문에 검색 가능성은 큰 문제가 아니라고 생각합니다. BLAS에 대해 충분히 알고있는 사람은 API를 어디에서 찾을 수 있는지 알 것입니다.

위치 대 키워드 인수와 관련하여 : 아직 여기에서 논의되지 않았지만 α 대각 행렬 인 C = αAB + βC 는 스칼라 α 만큼 효율적이고 쉽게 구현 될 수 있다고 생각합니다. 이러한 확장을 위해서는 키워드 인자로는 불가능한 α 유형을 디스패치 할 수 있어야합니다.

또한 비교 환형 eltype의 경우 muladd!(α', B', A', β', C') (가상 인수 순서)를 호출하여 C = ABα + Cβ 를 효율적으로 계산할 수 있습니다. 지연 래퍼 Adjoint(α) 및 Adjoint(β) 에서 디스패치 할 수 있어야 할 수 있습니다. (나는 개인적으로 Julia에서 비 교환 수를 사용하지 않으므로 이것은 아마도 매우 가설 적입니다.)

이 곱하기 추가 기능이 라이브러리 구현 자와 같은 숙련 된 프로그래머를위한 저수준 API라는 @Jutho 의 요점에 동의합니다. 확장 성이이 API에 대해 우선 순위가 높고 위치 인수가 갈 길이라고 생각합니다.

키워드 인수를 피하는 또 다른 인수는 @andreasnoack이 https://github.com/JuliaLang/julia/issues/23919#issuecomment -365762889 전에 말한 것입니다.

α 및 β 도 BLAS를 알지 않는 한 매우 직관적이지 않습니다.

@tkf , 물론, 내 주장은 β != 0 의 실제 사용 횟수가 β == 0 보다 적을 것이며이를 필요로하는 사람들은 이것이 약간 더 일반적이라는 사실에 놀라지 않을 것입니다. mul! 아래의 동작. 따라서, 특히 인수 순서가 엉망이 되었기 때문에 (적어도 muladd! 로) 새로운 이름으로 이것을 분리하는 이득을 보지 못합니다. 새로운 방법이어야한다면 addmul! 대한 귀하의 주장에도 공감합니다.

필요한 사람들은 mul! 에서 약간 더 일반적인 동작을 발견해도 놀라지 않을 것입니다.

나는이 점에 동의한다.

따라서 나는 이것을 새로운 이름으로 분리하는 이득을 보지 못합니다.

약간의 피해를 보지 않는 한 다른 사람들이 혜택을 보는 것이기 때문에 전 세계적으로 이익이라고 생각합니다.

특히 인수 순서가 엉망이기 때문에 (적어도 muladd! )

나는 당신이 이것을 해로 간주하고 나는 요점을 얻었습니다. muladd! / addmul! 대한 다른 혜택이 더 중요하다고 생각합니다.

나는 당신이 이것을 해로 간주하고 나는 요점을 얻었습니다. muladd! / addmul!의 다른 혜택이라고 생각합니다. 더 중요합니다.

그것은 실제로 mul! 가 곱셈과 관련된 여러 BLAS 연산에 대한 단일 진입 점이라는 사실과 함께 실제로 해를 끼칩니다. α 및 β에 대한 전체 액세스를 제공하지 않음으로써 제한되기 때문입니다. 이제 muladd! 하면 요청 된 작업의 약간의 차이에 따라 인수로 쉽게 캡처 할 수 있으며 실제로 BLAS API의 인수로 캡처 할 수있는 두 가지 다른 진입 점이 있습니다. . BLAS API에 대한 전체 액세스 권한을 제공하지 않는 것이 Julia의 실수라고 생각합니다 (@tkf를 수정 해 주셔서 감사합니다). 오래된 끔찍한 포트란 명명 규칙에도 불구하고이 사람들은 왜 이런 식으로 일을하는지 알고있었습니다. 하지만 마찬가지로이 연산군 (즉 α와 β로 매개 변수화 된 2- 파라미터 연산군)은 BLAS에서와 같이 단일 진입 점 아래에 함께 속한다고 생각합니다.

내 관점에서 가장 유효한 카운터 인수는 C 의 원본 데이터에 액세스할지 여부의 차이입니다. 그러나 Julia가 제로 결과를 보장하는 방법으로 false 곱하기를 받아 들였다는 사실을 감안할 때, 다른 요소가 NaN 경우에도 이것도 처리되었다고 생각합니다. 그러나 아마도이 사실은 더 잘 전달 / 문서화되어야 할 필요가있을 것이며 (문서를 읽은 지 오래되었습니다). (그래서 KrylovKit.jl에서 0으로 임의의 벡터와 유사한 사용자 유형을 초기화하려면 fill! 메서드가 필요합니다.하지만 이제는 대신 rmul!(x,false) 만 할 수 있다는 것을 알고 있습니다. 그래서 나는 fill! 가 구현되도록 강요 할 필요가 없습니다).

muladd! / addmul!의 다른 혜택이라고 생각합니다. 더 중요합니다.

그렇다면 질문을 뒤집어 보겠습니다. 새로운 방법을 사용할 때 얻을 수있는 다른 이점은 무엇입니까? 요약을 다시 읽었지만 방금 언급 한 C 액세스 지점 만 볼 수 있습니다.

나는 오늘 아침 아내에게 수술 이름을 짓는 것과 관련하여 Julia 커뮤니티에서 2 개월 동안 긴 대화가 있었다고 말했습니다. 그녀는 "프레드!"라고 불렀습니다. -두문자어도없고, 깊은 의미도없고, 좋은 이름 일뿐입니다. 그녀를 대신해서 이걸 내놓으세요.

그녀가 느낌표를 포함해서 다행입니다! 😄

우선, 만일을 대비하여, 저의 우려는 쓰기 가능성이나 발견 가능성이 아닌 코드의 가독성에서 비롯된다는 점을 분명히하겠습니다. 코드를 한 번 작성하지만 여러 번 읽습니다.

새로운 방법의 다른 이점은 무엇입니까?

언급했듯이 출력 대 입력-출력 매개 변수 인수가 가장 중요하다고 생각합니다. 하지만 이것이 _C = αAB + βC_가 _C = AB_와 다른 이유 중 하나 일뿐입니다. 또한 전자의 표현이 후자의 엄격한 "수퍼 세트"라는 점에서 차이가 있다는 단순한 사실은 코드에서 명확한 시각적 표시가 필요하다고 생각합니다. 다른 이름은 중급 프로그래머 (또는 약간 집중되지 않은 고급 프로그래머)가 코드를 훑어보고 mul! 보다 이상한 것을 사용하고 있음을 알아 차리는 데 도움이됩니다.

방금 설문 조사를 다시 확인했는데 (위의 "추가로드"를 클릭해야 함) 일부 투표가 mul! 에서 muladd! 로 이동 한 것 같습니다. 마지막으로봤을 때 mul! 이 이겼습니다. 그들이 이사하기 전에 여기에 기록합시다 : 웃음 :

• mul! : 6
• addmul! : 2
• muladd! : 8
• 다른 것 : 1

조금 더 진지하게, 나는 여전히이 데이터가 mul! 또는 muladd! 다른 것보다 명확하게 표시하지 않는다고 생각합니다. ( addmul! 이 소수임을 보여 주지만 : sob :)

우리가 갇힌 것처럼 느껴집니다. 우리는 어떻게 나아갈까요?

대신 gemm! 라고 부르시겠습니까?

그냥 gemm이라고 부르세요! 대신?

나는 이것이 농담이기를 바랍니다 ... 행렬 * 벡터에 대해 gemm!(α, A::Matrix, x::Vector, β, y::Vector) = gemv!(α, A, x, β, y) 을 제안하지 않는 한.

이미 존재하는 (희소 행렬이있는) mul! 인터페이스를 그대로두고 PR을 병합하고 개선 사항을 적용하고 다른 PR에 muladd! 을 추가할지 여부를 걱정할 수 있습니까? ?

여기있는 모든 사람들에게 이미 분명한 것이지만 저는 그저 투표가

• mul! 대 muladd!

그러나

• mul! 대 ( mul! 및 muladd! )

즉, 단일 대신에 두 개의 돌연변이 곱셈 함수가 있습니다.

mul! 찬성 게시물을 올릴 때마다 투표가 mul! 에서 ( mul! 및 muladd! )로 이동하는 것처럼 보였기 때문에 더 이상 게시하지 않기로 결정했습니다.

그러나 질문이 있습니까? 현재 과반수 투표로 진행하고 동시에 mul!(C,A,B) 및 muladd!(A,B,C,α=true,β=true) 를 보유하고 axpy! 및 axpby! 으로 대체하는 PR을 준비하고 싶습니다. 더 많은 줄리안 이름 add! , add!(y, x, α=true, β=true) 또는 add!(x, y, α=true, β=true) 이어야합니다 (명확성을 위해 y 는 변형 됨). 또는 다른 것?

명확하지 않은 경우 muladd!(A,B,C) 는 변경된 인수가 먼저 적용 되는 규칙을 위반합니다.

이미 존재하는 mul! 인터페이스를 종료 할 수 있습니까?

@jebej 저는이 "역 호환성"주장이 광범위하게 논의되었다고 생각합니다. 그러나 그것은 누구에게도 설득력이 없습니다 (투표를 보면 나 뿐만이 아닙니다).

다른 PR에 muladd! 을 추가 할 것인지 걱정하십니까?

공개 API를 깨는 것은 나쁘다. 따라서 우리가 mul! 라고 말하면 영원히 mul! (이론상 LinearAlgebra는 API를 깨기 위해 주요 버전을 올릴 수 있습니다).

axpy! 및 axpby! 을 더 많은 줄리안 이름 add! 대체하는 PR을 준비하고 싶습니다. add!(y, x, α=true, β=true) 또는 add!(x, y, α=true, β=true) 이어야합니다.

@ Jutho 감사합니다, 그거 좋을 것입니다! multiply-add API의 호출 서명을 결정하면 인수 순서를 선택하는 것이 간단하다고 생각합니다.

muladd!(A,B,C) 는 변경된 인수가 먼저 적용 되는 규칙을 위반합니다.

@simonbyrne 그러나 (https://github.com/JuliaLang/julia/issues/23919#issuecomment-426881998에서 이미 언급했듯이), lmul! 및 ldiv! 첫 번째가 아닌 인수를 변경합니다. 그래서 저는 우리가 muladd!(A,B,C,α,β) 를 선택에서 제외 할 필요가없고 오히려이 서명의 부정적인 점으로 간주 할 필요가 있다고 생각합니다.

(하지만 "textual order"API를 사용하려면 muladd!(α, A, B, β, C) 사용합니다.)

그건 그렇고, 투표 결과로 내가 이해하지 못하는 것은 muladd! 및 addmul! 의 비대칭입니다. C = βC + αAB 를 쓰면 addmul! 이 더 자연스러워 보입니다.

@tkf 먼저 어떤 작업을하는지에 관한 것입니다. 나에게 addmul! 는 (A+B)C 에서처럼 먼저 덧셈을 한 다음 곱하기를 제안합니다. 물론 주관적입니다. 그러나 좋은 이름은 직관에 호소해야합니다.

아, 알겠습니다.

이것이 여전히 멈 췄기 때문에 내 제안에는 함수 정의로 구성된 사용 패턴이 있습니다 (초당 @callexpr )

@callexpr(C .= β*C + α*A*B) = implementation(C, β, α, A, B)
@callexpr(C .= β*C + A*B) = implementation(C, β, true, A, B)

그리고 좀 더 디스패치 친화적 인 양식 (두 번째로 @callname )

function @callname(β*C + A*B)(C::Number, β::Number, A::Number, B::Number)
     β*C + A*B
end

그리고 전화

@callexpr(A .= 2*C + A*B)
@callexpr(2*3 + 3*2)

그리고 아무도 callexpr 대수 연산을 고유 한 함수 이름 (인수 기호에 의존하지 않고 연산과 연산 순서에만 의존 함)으로 어떻게 엉망으로 만들지 걱정할 필요가 없습니다.
나는 구현에 대해 조금 생각했고 그것은 잘 할 수있을 것이다.

@mschauer 나는 그것이 흥미로운 방향이라고 생각합니다. 새로운 문제를 열 ​​수 있습니까? 제안하는 API는 다른 많은 문제를 해결할 수 있습니다. 해결할 수있는 문제의 단일 사례를 해결하는 것보다 신중한 설계 프로세스를 거쳐야한다고 생각합니다.

그래서 1.1의 기능 동결이 다음 주라는 소문을 들었습니다. 다음 마이너 릴리스는 "단지"4 개월 남았지 만 1.1 버전에서 사용할 수 있다면 정말 좋을 것입니다.

어쨌든 PR을 병합하기 전에 호출 서명 (인수 및 키워드의 순서 여부)을 결정해야합니다.

그러니 다시 투표를합시다 (좋은 자극제라는 것을 알았으므로).

_If_ _C = ABα + Cβ_에 대해 muladd! 를 사용합니다. 가장 좋아하는 통화 서명은 무엇입니까?

• : +1 : muladd!(C, A, B, α, β)
• : -1 : muladd!(A, B, C, α, β)
• : smile : muladd!(C, A, B; α, β) (: +1 :과 같지만 키워드 인자는 b)
• : tada : muladd!(A, B, C; α, β) (: -1 :과 같지만 키워드 인수 포함)
• : 혼란 : muladd!(A, B, α, C, β)
• : heart : 다른 것

염두에두고있는 다른 키워드 인수 이름이있는 경우 α 및 β 사용하여 투표 한 다음 어떤 이름이 더 좋은지 의견을 말하십시오.

이름이 무엇인지 결정하지 않았으므로 mul! 에 대해서도 수행해야합니다.

_If_ 우리는 _C = ABα + Cβ_에 mul! 를 사용합니다. 가장 좋아하는 통화 서명은 무엇입니까?

• : +1 : mul!(C, A, B, α, β)
• : -1 : mul!(A, B, C, α, β)
• : smile : mul!(C, A, B; α, β) (: +1 :과 같지만 키워드 인자는 포함)
• : tada : mul!(A, B, C; α, β) (불가능)
• : 혼란 : mul!(A, B, α, C, β)
• : heart : 다른 것

참고 : 기존 API mul!(C, A, B) 은 (는) 변경하지 않습니다.

참고 : 기존 API mul!(C, A, B) 은 (는) 변경하지 않습니다.

저는이 사실에 충분히주의를 기울이지 않았습니다. 이미 mul! 있고 이것이 의미하는 바입니다.

mul!(Y, A, B) -> Y

행렬-행렬 또는 행렬-벡터 곱 A*B 하고 결과를 Y 에 저장하여 Y 의 기존 값을 덮어 씁니다. Y 는 A 또는 B 로 별칭을 지정하지 않아야합니다.

이를 감안할 때 다음과 같이 확장하는 것이 매우 자연스러워 보입니다.

mul!(Y, A, B) -> Y
mul!(Y, A, B, α) -> Y
mul!(Y, A, B, α, β) -> Y

행렬-행렬 또는 행렬-벡터 곱 A*B 하고 결과를 Y 에 저장하여 Y 의 기존 값을 덮어 씁니다. Y 는 A 또는 B 로 별칭을 지정해서는 안됩니다. 스칼라 값 α 가 제공되면 A*B 대신 α*A*B 가 계산됩니다. 스칼라 값 β 가 제공되면 α*A*B + β*Y 가 대신 계산됩니다. 이러한 변형에는 동일한 별칭 제한이 적용됩니다.

그러나 나는 이것에 대해 큰 우려가 있다고 생각한다. A*B*C*D 를 Y 로 계산하는 것이 적어도 mul!(Y, A, B, C, D) 가 당연해 보인다. 그리고 그 일반적인 개념은 mul!(Y, A, B, α, β) 컴퓨팅 α*A*B + β*C . 게다가, A*B*C*D 을 Y 로 계산하는 것이 유용하고 효율적으로 수행 할 수있는 것 같고 중간 할당을 피할 수 있으므로 그 의미를 차단하고 싶지 않습니다. .

mul! 의 다른 자연적인 일반화를 염두에두고 여기에 또 다른 생각이 있습니다.

mul!(Y, α, A, B) # Y .= α*A*B

이것은 args 를 곱하여 out 에 계산하고 쓰는 mul!(out, args...) 의 일반 모델에 적합합니다. 특별한 경우가 아니라 α 를 스칼라로 처리하기 위해 디스패치에 의존합니다. 이것은 곱하는 또 다른 일입니다. α 가 스칼라이고 A , B 및 Y 가 행렬 인 경우 BLAS로 디스패치하여이를 매우 효율적으로 수행 할 수 있습니다. 그렇지 않으면 일반적인 구현을 가질 수 있습니다.

또한 비 교환 필드 (예 : 쿼터니언)에있는 경우 α 의한 배율 조정이 발생하는 쪽을 제어 할 수 있습니다. mul!(Y, A, B, α) 배율은 α 왼쪽 대신 오른쪽 :

mul!(Y, A, B, α) # Y .= A*B*α

예, 쿼터니언에 대해 BLAS를 호출 할 수는 없지만 일반적이며 여전히 합리적으로 효율적으로 수행 할 수 있습니다 (어쨌든 BLAS 호출로 변환 할 수도 있음).

Y .= α*A*B 대한 접근 방식을 가정하면 다음 질문이됩니다. Y 확장 및 증분

mul!((β, Y), α, A, B) # Y .= β*Y .+ α*A*B

조금 이상하지만 작동합니다. 그리고 비 교환 필드에서 다음과 같이 오른쪽에 Y 에 β 을 곱하도록 요청할 수 있습니다.

mul!((Y, β), α, A, B) # Y .= Y*β .+ α*A*B

비 교환 필드에서 완전히 일반화하면 다음과 같이 왼쪽과 오른쪽 모두에서 확장 할 수 있습니다.

mul!((β₁, Y, β₂), α₁, A, B, α₂) # Y .= β₁*Y*β₂ + α₁*A*B*α₂

물론 이것은 약간 이상하고 이에 대한 BLAS 연산이 없습니다.하지만 GEMM의 일반화로 많은 것을 표현할 수 있고 불쾌한 if / else를 수행하지 않고도 BLAS 연산에 사소하게 전달할 수 있습니다. 가지.

저는 @StefanKarpinski 의 제안을 기본 API 호출로 정말 좋아하지만 이것이 실제로 사용자에게 정보를 노출하는 방법인지 여부도 생각하고 있습니다. IMO는 결국 관련 매크로처럼 단순 해 보일 것입니다.

@affine! Y = β₁*Y*β₂ + α₁*A*B*α₂

기본 기능은 @StefanKarpinski가 제안하는 것과

그러나 우리는 여기서 더 나아가 야합니다. 나는 당신이 그것을위한 API와 제네릭 함수를 만들면 누군가 그것을 효율적으로 수행하는 Julia 라이브러리를 만들 것이라고 정말로 생각한다. 그래서 나는 우리가 여기서 BLAS를 고수해서는 안된다는 것에 동의한다. MatrixChainMultiply.jl과 같은 것들은 이미 다중 행렬 계산을위한 DSL을 구축하고 있으며 DiffEq는 아핀 연산자 표현식으로 자체 작업을 수행하고 있습니다. Base에서 affine 표현식에 대한 표현이 하나만 있으면 모든 작업이 동일한 것에 대해 정의 할 수 있습니다.

@dlfivefifty 는 전에 게으른 선형 대수학을 살펴 보았지만 여기에서 실제로 부활해야한다고 생각합니다. 방송의 게으른 표현을 구축하는 것은 추상 배열과 대체 계산 하드웨어에서 요소 별 작업을 수행하는 데 중요했습니다. 선형 대수에도 동일하게 필요합니다. 선형 대수 표현식을 표현하면 Julia BLAS에서 즉석에서 새로운 BLAS 커널을 정의하거나 방정식을 GPU / TPU로 전송할 수 있습니다.

본질적으로 과학 컴퓨팅의 모든 계산은 요소 별 및 선형 대수 연산으로 귀결됩니다. 따라서 두 가지 모두에 대한 높은 수준의 설명은 메타 프로그래밍하고 새로운 설계를 탐색하는 도구를 구축하는 데 도움이됩니다.

이 제안에 대해 더 많이 생각해야하지만 지금은 임시없이 A*B*C 를 계산하고 싶지 않다고 생각합니다. 일시적인 것을 피하기 위해 많은 산술 연산을 지불해야 할 것 같습니다.

임시없이 A*B*C 를 계산하고 싶지 않다고 생각합니다.

그러나 mul! 이미 출력 배열이 있습니다. 그것이 도움이되는지 아닌지 잘 모르겠습니다. 어쨌든 구현 세부 사항처럼 보입니다. API mul!(Y, A, B, C...) 는 계산하려는 것을 표현하고 구현에서이를 수행하는 가장 좋은 방법을 선택할 수 있도록합니다. 이것이 일반적인 목표였습니다.

저는 @StefanKarpinski 의 제안을 기본 API 호출로 정말 좋아하지만 이것이 실제로 사용자에게 정보를 노출하는 방법인지 여부도 생각하고 있습니다.

@ChrisRackauckas : 당신이 들어가는 것은 외부 패키지에서 탐구 할 수 있고 탐구해야한다고 생각합니다. 게으름, 원하는 계산을 작성하고 최적화 방법을 알고있는 특정 대수 패턴과 일치하는 부분을 선택하도록하는 최적화 등. 이와 같이 mul! 사용하는 것은 우리가이 수준에서 원하는 일반적인 작업이지만 이해하기 쉬운 작업처럼 보입니다.

mul!(Y, α, A, B) 에 대한 실질적인 논쟁이 없다는 점에 유의하십시오. Y .= α*A*B 를 의미하는 것은 대체 무엇을 의미할까요? 그래서 나에게 유일한 열린 질문은 행렬과 왼쪽 및 / 또는 오른쪽 스칼라와 함께 튜플을 사용하는 것이 출력 배열을 증가시키고 크기를 조정하려는 것을 표현하는 합리적인 방법인지 여부입니다. 일반적인 경우는 다음과 같습니다.

1. mul!(Y::Matrx, args...) : Y .= *(args...)
2. mul!((β, Y)::{Number, Matrix}, args...) : Y .= β*Y + *(args...)
3. mul!((Y, β)::{Matrix, Number}, args...) : Y .= Y*β + *(args...)
4. mul!((β₁, Y, β₂)::{Number, Matrix, Number}, args...) : Y .= β₁*Y*β₂ + *(args...)

첫 번째 인수에 대해 다른 것은 허용되지 않습니다. 이는 선택적으로 스케일링과 결합하여 출력 배열에 덮어 쓰거나 누적하는 것이 합당한 다른 작업에 대한보다 일반적인 규칙으로 채택 될 수 있습니다.

mul!(out, args...) 와 GEMM과 같은 인터페이스를 "병합"하는 것은 나에게 발생하지 않았습니다! 나는 그것의 확장 성을 좋아한다 (그러나 아래에 답장을 쓰기 시작하고 지금 나는 확실하지 않다 ...)

그러나 내 걱정은 과부하 인터페이스로 사용하기 쉽다는 것입니다. 중첩 된 튜플에 대해 잘 작동하려면 유형 시스템에 의존해야합니다. 중첩 된 튜플이 Julia의 유형 시스템에서 플랫 튜플만큼 잘 작동합니까? Tuple{A1,B1,C1,D1} 가 Tuple{A2,B2,C2,D2} 보류보다 더 구체적인 경우 " Tuple{Tuple{A1,B1},C1,D1} 가 Tuple{Tuple{A2,B2},C2,D2} 보다 더 구체적인지 궁금합니다. 그렇지 않으면 오버로딩 API로 사용하는 것이 까다로울 것입니다.

복잡한 행렬에 대해 재 해석 해킹을 사용하려면 스칼라 유형을 디스패치해야합니다 (PR # 29634에서 가져온 것이므로 함수 이름에주의하지 마십시오).

https://github.com/JuliaLang/julia/blob/fae1a7a3ae646c7ea1c08982976b57096fb0ae8d/stdlib/LinearAlgebra/src/matmul.jl#L157 -L169

또 다른 걱정은 이것이 계산 그래프 실행기에 대해 다소 제한된 인터페이스라는 것입니다. multiply-add 인터페이스의 주요 목적은 라이브러리 구현자가 효율적으로 구현할 수있는 작은 재사용 가능한 계산 커널을 정의 할 수 있도록 오버로딩 API를 제공하는 것입니다. 즉, _C = ABα_ 만 구현할 수 있고 _αAB_는 구현할 수 없습니다 (https://github.com/JuliaLang/julia/pull/29634#issuecomment-443103667 참조). 비교 환형 eltype에 대해 _α₁ABα₂_를 지원하려면 임시 배열이 필요하거나 산술 연산 수를 늘려야합니다. 어떤 사용자가 원하는지 명확하지 않으며 이상적으로는이를 구성 할 수 있어야합니다. 이 시점에서 우리는 실행 메커니즘과 분리 된 계산 그래프 표현이 필요합니다. 이것은 외부 패키지 (예 : LazyArrays.jl, MappedArrays.jl)에서 탐색하는 것이 더 낫다고 생각합니다. 그러나 언젠가 대부분의 사용 사례를 다루는 구현 전략을 찾을 수 있다면 mul! 를 기본 진입 점으로 사용하는 것이 합리적입니다. 나는 이것이 실제로 muladd! 를 선호하는 또 다른 이유라고 생각합니다. 향후 호출 API를위한 공간 할당.

이 제안에 대해 더 많이 생각해야하지만, 지금은 임시없이 A B C를 계산하고 싶지 않다고 생각합니다. 일시적인 것을 피하기 위해 많은 산술 연산을 지불해야 할 것 같습니다.

모든 것을 평가하는 가장 효율적인 방법은 항상 쌍 단위 수축을 사용하는 것입니다. 따라서 여러 행렬을 곱하는 것은 특별한 경우 일 뿐이므로 쌍으로 곱해야합니다 (물론 최상의 순서는 사소한 문제가 아닙니다). 그래서 저는 mul!(Y,X1,X2,X3...) 가 그렇게 유용한 기본 요소가 아니라고 생각합니다. 그리고 결국 이것이 mul! 라고 생각합니다. 개발자가 특정 유형에 대해 오버로드 할 수있는 원시 작업입니다. 더 복잡한 연산은 예를 들어 매크로를 사용하여 더 높은 수준의 구성을 사용하여 작성 될 수 있으며, 예를 들어 계산 그래프를 만들 수 있으며, 이는 결국 mul! 와 같은 기본 연산을 호출하여 평가됩니다. 물론, 그 프리미티브는 @StefanKarpinski가 언급 한 비 교환 적 사례와 같은 경우를 포함하기에 충분히 일반적 일 수 있습니다.

매트릭스 곱셈 / 텐서 수축이 포함되지 않는 한, 원시 연산 측면에서 생각하는 것이 그다지 유용하지 않으며 방송처럼 모든 것을 융합하는 것이 유익 할 수 있다는 것은 사실입니다.

일반적으로 Base에 기본 게으른 표현 / 계산 그래프 유형을 사용하는 것이 좋을 것이라는 데 동의하지만 mul! 가 그것을 구성하는 방법이라고 생각하지 않습니다.

@tkf :

그러나 내 걱정은 과부하 인터페이스로 사용하기 쉽다는 것입니다. 중첩 된 튜플에 대해 잘 작동하려면 유형 시스템에 의존해야합니다. 중첩 된 튜플이 Julia의 유형 시스템에서 플랫 튜플만큼 잘 작동합니까?

예, 우리는 모두 잘하고 있습니다. 중첩이 어디로 들어오는 지 확실하지 않지만 튜플에 일부를 전달하는 것은 즉시 인수를 전달하는 것만 큼 효율적입니다. 정확히 동일한 방식으로 구현됩니다.

즉, _C = ABα_ 만 구현할 수 있으며 _αAB_는 구현할 수 없습니다.

헷갈리네요 ... mul!(C, A, B, α) 및 mul!(C, α, A, B) 쓸 수 있습니다. mul!(C, α₁, A, α₂, B, α₃) 라고 쓸 수도 있습니다. 이것은 지금까지 제안 된 가장 유연한 일반 행렬 곱셈 API처럼 보입니다.

또 다른 걱정은 이것이 계산 그래프 실행기에 대해 다소 제한된 인터페이스라는 것입니다. multiply-add 인터페이스의 주요 목적은 라이브러리 구현자가 효율적으로 구현할 수있는 작은 재사용 가능한 계산 커널을 정의 할 수 있도록 오버로딩 API를 제공하는 것입니다.

이 시점에서 우리는 실행 메커니즘과 분리 된 계산 그래프 표현이 필요합니다.

그럴 수도 있지만 외부 패키지로 개발할 수 있고 개발해야하는 곳이 아닙니다. 이 특정 문제를 해결하는 데 필요한 것은 BLAS 작업에 전달할 수있는 항목을 일반화하는 행렬 곱셈 API뿐입니다. 이것이 바로 이것이하는 일입니다.

@Jutho

따라서 여러 행렬을 곱하는 것은 특별한 경우 일 뿐이므로 쌍으로 곱해야합니다 (물론 최상의 순서는 사소한 문제가 아닙니다). 그래서 저는 mul!(Y,X1,X2,X3...) 가 그렇게 유용한 기본 요소가 아니라고 생각합니다.

mul! 연산을 사용하면 구현시 유용한 속성 인 곱셈 순서를 선택할 수 있습니다. 실제로, 잠재적으로 그렇게 할 수있는 능력은 우리가 * 연산을 처음에 n-ary로 구문 분석하도록 만든 이유였으며 동일한 추론이 mul! 더 많이 적용됩니다. , 아마도 당신은 성능에 대해 충분히 관심을 가질 것입니다.

일반적으로 귀하가 mul! 에 대한 제 제안에 대해 반대하는지 또는 반대하는지 알 수 없습니다.

중첩이 어디로 들어오는 지 확실하지 않지만 튜플에서 일부를 전달하는 것은 즉시 인수를 전달하는 것만 큼 효율적입니다.

현재의 LinearAlgebra조차도 다소 취약하기 때문에 효율성에 대해 걱정하지 않고 오히려 디스패치 및 메서드 모호함을 느꼈습니다 (유형 시스템에 대한 이해가 부족하기 때문일 수 있습니다. 때로는 놀랍습니다). 메서드의 해결이 모든 위치 인수의 튜플 유형을 교차하여 수행한다고 생각했기 때문에 중첩 된 튜플을 언급했습니다. 그것은 당신에게 평평한 튜플을 제공합니다. 첫 번째 인수에 튜플을 사용하면 중첩 된 튜플이 있습니다.

즉, _C = ABα_ 만 구현할 수 있으며 _αAB_는 구현할 수 없습니다.

헷갈리네요 ... mul!(C, A, B, α) 및 mul!(C, α, A, B) 쓸 수 있습니다.

"우리는 _C = ABα_ 를 _C = AB_ _αAB_ 와 같은 다른 후보는 모든 매트릭스 유형 조합에서 효율적으로 구현할 수 없습니다." (효율적으로는 큰 O 시간 복잡도를 의미합니다.) 이것이 실제로 사실인지 확실하지는 않지만 적어도 희소 행렬의 경우 다른 두 가지 옵션이 없습니다.

이 시점에서 우리는 실행 메커니즘과 분리 된 계산 그래프 표현이 필요합니다.

그럴 수도 있지만 외부 패키지로 개발할 수 있고 개발해야하는 곳이 아닙니다.

그것이 바로 나의 요점입니다. 이 API를 그러한 사용을위한 최소한의 구성 요소로 보는 것이 좋습니다 (물론 전체 목적은 아닙니다). vararg mul! 의 구현 및 디자인은 사람들이 외부 패키지의 디자인 공간을 탐색 한 후에 수행 할 수 있습니다.

현재 mul! 조차도 유형에 대한 디스패치가 이미 "깨졌습니다". SubArray 및 Adjoint 와 같은 구성 가능한 배열 유형을 사용하는 데 필요한 모호성 재정의의 조합 증가가 있습니다.

해결책은 특성을 사용하는 것이며 LazyArrays.jl에는 특성이있는 mul! 의 개념 증명 버전이 있습니다.

그러나 이것은 API보다 구현에 대한 논의에 가깝습니다. 그러나 튜플을 사용하여 용어를 그룹화하는 것은 잘못된 느낌입니다. 이것이 유형 시스템이있는 이유가 아닌가요? 이 경우 LazyArrays.jl 솔루션에 도달합니다.

멀! 연산은 구현에서 유용한 속성 인 곱셈의 순서를 선택할 수 있도록합니다. 실제로, 잠재적으로 그렇게 할 수있는 능력은 우리가 처음에 * 연산을 n-ary로 구문 분석하도록 만든 이유였으며 동일한 추론이 mul에 더 많이 적용됩니다! 당신이 그것을 사용한다면 아마 성능에 대해 충분히 신경을 쓰게 될 것입니다.

* 가 n -ary로 구문 분석되는 것은 매우 유용합니다. TensorOperations.jl에서 이것을 사용하여 실제로 수축 순서를 최적화하는 @tensoropt 매크로를 구현합니다. n -ary 버전의 mul! 덜 유용하다는 것은 효율성 측면에서 결과를 넣을 수있는 사전 할당 된 장소를 제공하는 데있어 중요하지 않기 때문입니다. 배열은 여전히 ​​함수 내부에 할당 된 다음 gc '되어야합니다. 실제로 TensorOperations.jl에서 여러 사람들은 대규모 임시 할당이 Julia의 gc 성능이 매우 좋지 않은 곳 중 하나라는 사실을 발견했습니다 (대부분 gc 시간이 50 %로 이어지는 경우가 많습니다).

따라서 내가 올바르게 이해한다면 @tkf 가 옹호하는 것처럼 mul! 을 진정한 원시 연산으로 제한 할 것입니다 : 스칼라 계수를 사용하여 두 행렬을 세 번째 행렬로 곱하는 것입니다. 예, 우리는 비 교환 대수에 대해 이것을 수행하는 가장 일반적인 방법을 생각할 수 있지만 지금 당장은 Julia의 mul! BLAS (gemm, gemv, ...)에서 제공하는 기능에 대한 편리한 액세스가 즉시 필요하다고 생각합니다.

튜플을 사용한 제안이 마음에 들지는 않지만 잠재적 인 혼란을 예견 할 수 있습니다.
사례 4에서 사례 2/3로 제한하는 것은 기본값 β₁ = 1 및 β₂ = 1 (또는 실제로 true )를 의미합니다. 그러나 둘 다 지정되지 않으면 갑자기 β₁ = β₂ = 0 ( false )를 의미합니다. 물론, mul!((Y,), args...) 아니라 mul!(Y, args...) 를 작성했기 때문에 구문이 약간 다릅니다. 결국 문서의 문제이므로이 점을 지적하고 싶었습니다.

요약하자면 저는이 구문에 반대하지 않습니다. 새로운 유형의 패러다임이 도입되고 있고 다른 곳에서도 따라야 할 것입니다. 내가 반대하는 것은 이것을 임의의 수의 행렬의 곱셈으로 즉시 일반화하고 싶다는 것입니다. 위에서 언급했듯이 나는 이점을 보지 못합니다.

@dlfivefifty : 그러나 이것은 API보다 구현에 대한 논의입니다. 그러나 튜플을 사용하여 용어를 그룹화하는 것은 잘못된 느낌입니다. 이것이 유형 시스템이있는 이유가 아닌가요? 이 경우 LazyArrays.jl 솔루션에 도달합니다.

그러나 우리는 여기서 완전한 lazy 배열을 사용하지 않을 것입니다. 이미 LazyArrays가 있습니다. 한편, Y 스케일링을 표현하는 방법이 필요합니다. 튜플을 사용하는 것은 그 적은 양의 구조를 표현하는 간단하고 가벼운 접근 방식처럼 보입니다. 누구든지 다른 제안이 있습니까? β₁ 및 β₂ 대해 lscale 및 / 또는 rscale 키워드를 가질 수 있지만 더 이상 우아하게 느껴지지 않고 중요하지는 않지만 가지고 있으면 좋습니다.

@Jutho : 따라서 내가 올바르게 이해한다면 @tkf 가 옹호하는 것처럼 mul! 을 진정한 원시 연산으로 제한 합니다 : 스칼라 계수를 사용하여 두 개의 행렬을 세 번째 행렬로 곱합니다. 예, 우리는 비 교환 대수에 대해 이것을 수행하는 가장 일반적인 방법을 생각할 수 있지만 지금 당장은 Julia의 mul! BLAS (gemm, gemv, ...)에서 제공하는 기능에 대한 편리한 액세스가 즉시 필요하다고 생각합니다.

mul! 대한 작업의 작은 하위 집합 만 정의해도 괜찮습니다. 구조적으로 유효한 BLAS 호출에 해당하는 작업 일 수도 있습니다. 다음과 같습니다.

# gemm: alpha = 1.0, beta = 0.0
mul!(Y::Matrix, A::Matrix, B::Matrix) # gemm! Y, A

# gemm: alpha = α, beta = 0.0 (these all do the same thing for BLAS types)
mul!(Y::Matrix, α::Number, A::Matrix, B::Matrix)
mul!(Y::Matrix, A::Matrix, α::Number, B::Matrix)
mul!(Y::Matrix, A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β (these all do the same thing for BLAS types)
mul!((β::Number, Y::Matrix), α::Number, A::Matrix, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, α::Number, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, B::Matrix, α::Number)
mul!((Y::Matrix, β::Number), α::Number, A::Matrix, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, α::Number, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β₁*β₂ (these all do the same thing for BLAS types)
mul!((β₁::Number, Y::Matrix, β₂::Number), α::Number, A::Matrix, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, α::Number, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, B::Matrix, α::Number)

무엇을 위해? BLAS 작업을 표현하는 방법에 많은 변화를 허용하는 이유는 무엇입니까?

1. 사람들이 자신의 의도를 표현할 수 있기 때문에, 의도가 왼쪽이나 오른쪽 또는 양쪽 모두에서 증가하는 것이라면 사람들이 그것을 표현하고 올바른 구현을 선택하도록 허용하지 않는 이유는 무엇입니까?

2. 비 교환 요소 유형에 대해서도 올바른 작업을 수행하는 일반적인 폴백을 가질 수 있습니다.

이 문제의 요점은 gemm을 포함하는 내부 행렬 곱셈을 일반화하는 것입니다! gemm보다 더 일반적입니다!. 그렇지 않으면 계속해서 gemm! 를 쓰지 않는 이유는 무엇입니까?

하지만 여기서는 전체 게으른 배열을 사용하지 않을 것입니다.

나는 "full lazy arrays"를 말하는 것이 아니라, 궁극적으로 컴파일 타임에 제거되는 Broadcasted 와 같은 의미에서 lazy를 제안합니다. 기본적으로 Applied 를 추가하여 함수의 지연 응용 프로그램을 나타내며 튜플 (컨텍스트가 포함되지 않음)을 사용하는 대신 다음과 같은 것을 갖게됩니다.

materialize!(applied(+, applied(*, α, A, B), applied(*, β, C)))

이것은 방송의 .* 표기법처럼 설탕 코팅을하여 더 읽기 쉽게 만들 수 있지만, 튜플 기반 제안과는 달리 원하는 것이 바로 명확하다고 생각합니다.

@StefanKarpinski , 앞서 말했듯이, 나는 미래의 증명이고 다른 숫자 유형으로 올바르게 일반화되는 인터페이스에 대해 고려해야한다는 데 확실히 동의합니다. 유일한 문제는 목록이 완전하지 않다는 것입니다. 원칙적으로 다음을 가질 수 있습니다.

mul!((β₁::Number, Y::Matrix, β₂::Number), α₁::Number, A::Matrix, α₂::Number, B::Matrix, α₃::Number)

모든 축소 된 버전, 즉 5 개의 스칼라 인수가 모두 없을 수있는 경우 2 ^ 5 = 32 개의 다른 가능성이 있습니다. 그리고 이것은 다른 행렬이나 벡터의 모든 가능성과 결합되었습니다.

나는 방송과 같은 접근 방식이 더 실현 가능하다는 @dlfivefifty에 동의합니다.

예, 몇 가지 옵션을 생략했음을 깨달았습니다.하지만 32 가지 방법이 나에게 그다지 미친 것 같지는 않습니다. 결국 수동으로 작성할 필요가 없습니다. 는 "방송과 같은 시스템"또는 우리가 쓸 수있는 게으른 평가 시스템을 추가 materialize!(applied(+, applied(*, α, A, B), applied(*, β, C))) 이 문제에 대한 범위 밖으로 훨씬 더 큰 추가 및 방법처럼 보인다. 우리가 원하는 것은 일반 행렬 곱셈을 철자하고 BLAS로 보낼 수있는 방법입니다. 우리 모두가 동의 할 수 없다면 사람들이 계속해서 gemm! 직접 전화를 걸도록하겠습니다.

예, 아마도 사실입니다. 스칼라 인수가 뒤쪽으로 들어가면 기본값을 쉽게 제공하는 것이 더 쉬울 것이라고 가정했습니다. 하지만 @eval 메타 프로그래밍으로 32 개의 정의를 모두 쉽게 생성 할 수 있다면 똑같이 좋습니다. (아시다시피 mul 는 gemm! 뿐만 아니라 gemv 및 trmm 및 ...입니다.)

BLAS 래퍼가 아니라는 점을 추가하겠습니다. stdlib에는 다른 순수 줄리아 특수 메서드가 있습니다. 또한이를 오버로딩 API로 사용하는 것이 중요합니다. 패키지 작성자는 특수 매트릭스 유형에 대해 mul! 를 정의 할 수 있습니다.

나는 이것이 내 입장이라고 생각한다.

1. SparseArrays.jl에 이미 존재하므로 mul!(C, A, B, a, b) 지원할 수도 있습니다.
2. 매트릭스 유형에 대한 디스패치가 제대로 확장되지 않으므로 다른 작업을 수행하면 안됩니다. (BandedMatrices.jl, BlockArrays.jl, LowRankApprox.jl 등의 관리자로서 경험을 통해 말할 수 있습니다.)
3. 디자인 기반의 특성은 확장 성이 좋지만 디자인 패턴이 이미 확립되어 있으므로 Applied 와 같은 방송을하는 것이 가장 좋습니다. 이 작업은 Julia 2.0까지 기다려야하며 내 요구에 맞는 LazyArrays.jl에서 프로토 타입이 계속 개발됩니다.

@dlfivefifty 마십시오 당신의 동음이의 어려움을 생각 mul!((Y, β), α, A, B) API가 같이 동일 mul!(Y, A, B, α, β) ? Transpose 와 같은 매트릭스 래퍼를 고려하면 2- 튜플과 3- 튜플을 포함하여 난이도를 높이는 것처럼 들립니다 (튜플이 Julia의 유형 시스템에서 특별한 경우라는 것을 알고 있지만).

1. SparseArrays.jl에 이미 존재하므로 mul!(C, A, B, a, b) 지원할 수도 있습니다.

누군가가 mul!(C, A, B, a, b) 을 완전히 생각하지 않고 C .= b*C + a*A*B 을 의미해야한다고 결정했다는 사실은 이것을 두 배로 줄여야 할 좋은 이유가 아닙니다. mul! 이 * 의 인플레 이스 버전이면 mul!(out, args...) 이 out .= *(args...) 이외의 다른 것을 의미 할 수있는 방법을 알 수 없습니다. 솔직히, 이것은 역사적 우연에 의해서만 존재하는 잘못 생각되고 일관성없는 API가 엉망인 시스템을 만드는 방법입니다. mul! 함수는 SparseArrays 내보내지지 않고 특정 메서드가 문서화되어 있지 않습니다. 따라서이 함수가 추가 되었기 때문에 추가되었을 수있는 잘못된 메서드를 확고히 할 수있는 가장 간단한 이유입니다. 공개하지 마십시오! 그 실수를 취소하고 대신 mul! 메서드를 삭제 / 이름을 바꿀 것을 제안합니다.

이 토론의 나머지 부분에서는 모든 이해 관계자가 표준 라이브러리 외부에서 특성 및 / 또는 게으름으로 더 멋진 일을하기를 원하기 때문에 다른 작업을 수행해서는 안되는 것처럼 들립니다. 물건을 삭제하는 것이 항상 좋기 때문에 나는 괜찮습니다.

이 토론의 나머지 부분에서는 모든 이해 관계자가 표준 라이브러리 외부에서 특성 및 / 또는 게으름으로 더 멋진 일을하기를 원하기 때문에 다른 작업을 수행해서는 안되는 것처럼 들립니다. 물건을 삭제하는 것이 항상 좋기 때문에 나는 괜찮습니다.

당신이 조금 지쳐있는 것 같습니다. 그러나 나는 그 결론이 사실이라고 생각하지 않습니다. 현재 제안이 확장 가능한 방식으로 구현 될 수 있고 패키지 개발자가 자신의 행렬 및 벡터 유형 (@tkf에서 언급 한대로)에 대해 해당 정의를 오버로드하는 것이 편리하도록 구현할 수 있다고 확신하는 경우 좋은 방법이 될 것입니다. 앞으로.

특히 패키지 개발자는 다음을 구현하기 만하면된다고 생각합니다.

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

그리고 아마도

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::Adjoint{<:MyMat}, α₂, B:: MyVecOrMat, α₃)
...

Julia Base (또는 LinearAlgebra 표준 라이브러리)는 모든 기본값 등을 처리합니다.

패키지 개발자는 다음을 구현하기 만하면된다고 생각합니다.

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

문서화하는 것이 좋습니다.

mul!((Y, β), A, B, α)

오버로드 할 서명으로. 이는 α 다른 위치가 큰 O 시간 복잡성을 변경하기 때문입니다. 참조 : https://github.com/JuliaLang/julia/pull/29634#issuecomment -443103667. 이것은 비 교환 수에 비 일류 처리를 제공합니다. 그러나 AFAICT는 여기에 아무도 실제로 비 교환 수를 사용하지 않으며 실제 필요가있을 때까지 기다려야한다고 생각합니다.

@StefanKarpinski 의 접근 방식에 대해 내가 좋아하는 한 가지는 시간 복잡도를 변경하지 않고 A (예 : Adjoint{_,<:SparseMatrixCSC} )의 _some_ 행렬 유형에 대해 mul!((Y, β), α::Diagonal, A, B) 대한 특수 메서드를 구현할 수 있다는 것입니다. . (이것은 내 응용 프로그램에 중요합니다.) 물론이 방법을 사용하려면 API, 특히 특수 메서드의 존재를 쿼리하는 방법에 대한 추가 논의가 필요합니다. 그래도 API를 확장 할 수있는 기회가 있다는 것은 대단합니다.

누군가 메서드 모호성에 대한 내 걱정을 명확히한다면 나는 그룹 별 튜플 접근 방식에 모두 참여할 것입니다.

이는 α의 다른 위치가 큰 O 시간 복잡도를 변경하기 때문입니다.

이것은 특별히 희소 행렬입니까? 나는 특히 밀도가 높은 행렬에 대해서는 그렇지 않습니다. 연결하는 구현에서 α 가 A 와 B 사이에있는 경우를 보여줍니다.

패키지 개발자는 구현하기 만하면된다고 생각합니다.

이것은 매우 간단합니다. BlockArrays.jl의 PseudoBlockMatrix 와 같이 strided 행렬처럼 동작하는 행렬이 있다고 가정 해 보겠습니다. 완벽하게 지원하기 위해 gemm! 우리의 모든 순열 오버라이드 (override) 할 필요가 PseudoBlockMatrix (1) 자체, (2) StridedMatrix , (3) Adjoint 의 자체를 , (4) Transpose s 자체, (5) Adjoint s of StridedMatrix , (6) Transpose s of StridedMatrix , 그리고 아마도 다른. 이것은 이미 6 ^ 3 = 216 개의 다른 조합입니다. 그런 다음 trmm! 를 지원하고 UpperTriangular , UnitUpperTriangular , 그들의 adjoints, 그들의 transposes 등으로 똑같이해야합니다. 그런 다음 gsmm! Symmetric 및 Hermitian 와 함께

그러나 많은 애플리케이션에서 우리는 행렬뿐만 아니라 하위 뷰, 특히 블록으로 작업하려는 블록 행렬에 대해 작업하기를 원합니다. 이제 위의 6 가지 조합과 함께 매트릭스 뷰의 모든 퍼뮤 레이션을 추가해야합니다.

이제 우리는 매우 복잡한 공용체 유형 인 StridedMatrix 와 관련된 수천 개의 재정의를 가지고 있습니다. 이것은 컴파일러에게는 너무 많은 시간이므로 using 시간이 몇 초가 아닌 몇 분 이상 걸립니다.

이 시점에서 현재 mul! 및 제안 된 확장 mul! 는 설계 상 결함이 있으므로 패키지 개발자는 이에 신경을 쓰지 않아야합니다. 다행히 LazyArrays.jl은 특성을 사용하는 임시 해결 방법을 제공합니다.

그래서 저는 @StefanKarpinski 가 좀 더 실질적인 재 설계를 추구 할 때까지 그대로 두는 것에 동의합니다. 디자인에 결함이있는 것에 노력을 투자하는 것은 누구의 시간을 잘 활용하지 않기 때문입니다.

@dlfivefifty , 스칼라 인수가 처리되는 방식 만 언급했습니다. 현재 mul!(C,A,B) 대해 이미 존재하는 다른 매트릭스 유형의 모든 컴 플리케이션은 물론 그대로 유지됩니다.

이는 α의 다른 위치가 큰 O 시간 복잡도를 변경하기 때문입니다.

이것은 특별히 희소 행렬입니까? 나는 특히 밀도가 높은 행렬에 대해서는 그렇지 않습니다. 연결하는 구현에서 α 가 A 와 B 사이에있는 경우를 보여줍니다.

@Jutho 일반적으로 α 를 가장 안쪽의 루프 위치에 넣을 수 없다고 생각합니다. 예를 들어,이 경우 α₁*A*B*α₃ 는 지원할 수 있지만 A*α₂*B 는 지원할 수 없습니다.

https://github.com/JuliaLang/julia/blob/11c5680d5620b0b64420055e8474a2b8cf757010/stdlib/LinearAlgebra/src/matmul.jl#L661 -L670

나는 적어도 생각 α₁ 또는 α₂ 에서 α₁*A*α₂*B*α₃ 가 될 1 점근 시간 복잡성이 증가하지 않도록합니다.

@dlfivefifty 하지만

아니요, Broadcasted 에 "primitive"가없는 것과 같은 방식으로 "primitive"가 없습니다. 하지만 현재로서는 "커널"문제를 해결하지 못합니다. 다음 단계는 ApplyStyle 와 함께 게으른 Applied 유형을 사용하도록 재 설계하는 것입니다. 그런 다음 순서가 중요하지 않은 방식으로 BLAS와 유사한 작업을 인식하는 MulAddStyle 가있을 수 있습니다.

나는 materialize! 또는 copyto! 를 프리미티브라고 부를 것입니다. 적어도 방송 메커니즘의 구성 요소입니다. 마찬가지로, LazyArrays.jl이 루프가있는 함수로 지연 표현을 낮추거나 언젠가는 ccall s를 외부 라이브러리로 낮추어야한다고 생각합니다. 이러한 함수의 이름이 mul! 이면 나쁠까요?

이것은 매우 간단합니다. BlockArrays.jl의 PseudoBlockMatrix와 같이 strided 행렬처럼 동작하는 행렬이 있다고 가정 해 보겠습니다. gemm을 완벽하게 지원합니다! PseudoBlockMatrix의 모든 순열을 (1) 자체, (2) StridedMatrix, (3) 자체의 인접, (4) 자신의 전치, (5) StridedMatrix의 인접, (6) StridedMatrix의 전치 및 가능한 다른 것으로 재정의해야합니다. . 이것은 이미 6 ^ 3 = 216 개의 다른 조합입니다. 그렇다면 trmm을 지원하고 싶습니다! 그리고 당신은 UpperTriangular, UnitUpperTriangular, 그들의 인접, 그들의 전치 등등에 대해 똑같이해야합니다. 그럼 gsmm! Symmetric 및 Hermitian과 함께.
그러나 많은 애플리케이션에서 우리는 행렬뿐만 아니라 하위 뷰, 특히 블록으로 작업하려는 블록 행렬에 대해 작업하기를 원합니다. 이제 위의 6 가지 조합과 함께 매트릭스 뷰의 모든 퍼뮤 레이션을 추가해야합니다.
이제 우리는 매우 복잡한 공용체 유형 인 StridedMatrix를 포함하는 수천 개의 재정의를 가지고 있습니다. 이것은 컴파일러에게 너무 많은 시간이므로 사용 시간이 몇 초가 아닌 몇 분 이상 걸립니다.

나는 현재 StridedArray 유형 유니온이 주요 디자인 결함이라는 데 확실히 동의합니다. 나는이 문제를 어느 시점에서 고치려는 당신의 시도를지지했습니다.

Strided.jl에서는 관련된 모든 행렬이 내 사용자 정의 유형 (Abstract)StridedView 일 때 mul! 만 구현합니다. A, B 및 C 유형이 혼합 될 때마다 Julia에게 Base / LinearAlgebra가이를 처리합니다. 물론 이것은 가능한 모든 기본 유형을 StridedView 유형으로 변환하려고 시도하는 @strided 매크로 환경에서 사용됩니다. 여기서 StridedView 는 동일한 (파라 메트릭) 유형을 사용하여 하위보기, 전치 및 인접, 특정 모양 변경을 나타낼 수 있습니다. 전반적으로 전체 곱셈 코드는 약 100 줄입니다.
https://github.com/Jutho/Strided.jl/blob/master/src/abstractstridedview.jl#L46 -L147
BLAS가 적용되지 않는 경우 네이티브 Julia 대체는 해당 패키지에서 제공하는보다 일반적인 mapreducedim! 기능을 사용하여 구현되며 LinearAlgebra 있는 것보다 덜 효율적입니다. 그러나 그것은 또한 다중 스레드입니다.

점근 시간 복잡성이 증가하지 않도록 α₁*A*α₂*B*α₃ 에서 α₁ 또는 α₂ 이상이 α₁ 이어야한다고 생각합니다.

@tkf , 나는 이러한 스칼라 계수가 기본값 one(T) 또는 더 나은 경우 true , 상수 전파 및 컴파일러 최적화가 자동으로 해당 곱셈을 제거한다고 가정합니다. 작동하지 않을 때 가장 안쪽 루프에서. 따라서 가장 일반적인 형식을 정의하는 것이 여전히 편리합니다.

1 ( true )의 모든 곱셈을 제거하기 위해 상수 전파에 의존 할 수 있는지 확실하지 않습니다. 예를 들어, eltype은 Matrix 있습니다. 이 경우 true * x ( x::Matrix )가 x 의 힙 할당 복사본을 만들어야한다고 생각합니다. Julia가 그것을 제거하기 위해 마술을 할 수 있습니까?

@Jutho 저는이 벤치 마크가 Julia가 어떤 경우에 중간 곱셈을 제거 할 수 없다는 것을 보여줍니다.

function simplemul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)
    <strong i="7">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="8">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="9">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="10">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(α₁ * A[i, 1] * α₂ * B[1, j] * α₃ +
                   α₁ * A[i, 1] * α₂ * B[1, j] * α₃)
        for k = 1:size(A, 2)
            acc += A[i, k] * α₂ * B[k, j]
        end
        Y[i, j] = α₁ * acc * α₃ + β₁ * Y[i, j] * β₂
    end
    return Y
end

function simplemul!((Y, β), A, B, α)
    <strong i="11">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="12">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="13">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="14">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(A[i, 1] * B[1, j] * α +
                   A[i, 1] * B[1, j] * α)
        for k = 1:size(A, 2)
            acc += A[i, k] * B[k, j]
        end
        Y[i, j] = acc * α + Y[i, j] * β
    end
    return Y
end

fullmul!(Y, A, B) = simplemul!((false, Y, false), true, A, true, B, true)
minmul!(Y, A, B) = simplemul!((Y, false), A, B, true)

using LinearAlgebra
k = 50
n = 50
A = [randn(k, k) for _ in 1:n, _ in 1:n]
B = [randn(k, k) for _ in 1:n]
Y = [zeros(k, k) for _ in 1:n]
<strong i="15">@assert</strong> mul!(copy(Y), A, B) == fullmul!(copy(Y), A, B) == minmul!(copy(Y), A, B)

using BenchmarkTools
<strong i="16">@btime</strong> mul!($Y, $A, $B)     # 63.845 ms (10400 allocations: 99.74 MiB)
<strong i="17">@btime</strong> fullmul!($Y, $A, $B) # 80.963 ms (16501 allocations: 158.24 MiB)
<strong i="18">@btime</strong> minmul!($Y, $A, $B)  # 64.017 ms (10901 allocations: 104.53 MiB)

좋은 벤치 마크. 나는 또한 이미 유사한 실험에 의해 이러한 할당이 실제로 제거되지 않을 것임을 이미 알고있었습니다. 이러한 경우 *(::One, x::Any) = x 및 *(x::Any, ::One) = x 만 정의하고 지금까지 사용자 유형이 필요하지 않은 특수 목적 One 싱글 톤 유형을 정의하는 것이 유용 할 수 있습니다. 그런 다음 기본값에 대한 최소한 α₂ , 수 One() .

아, 네, 영리합니다! 나는 처음에 α₁ * A * α₂ * B * α₃ 를 지원해도 괜찮다고 생각했지만 다른 문제를 발견했다고 생각합니다. A 이 행렬의 행렬이고 (예를 들어) 우리가해야 할 일이 수학적으로 모호합니다. α₁ 는 행렬입니다. α 위치에서 스칼라가 아닌 인수를 _ 절대 지원하지 않으면 문제가되지 않습니다. 그러나, 그것은 불가능 제시 할 수 Y .= β₁*Y*β₂ + *(args...) 의 정신 모델로 mul!((β₁, Y, β₂), args...) . 게다가 대각 행렬을 α₁ 또는 α₂ 로 전달할 수 있다면 정말 좋을 것입니다. 거의 "무료로"계산할 수 있기 때문입니다 (그리고 응용 프로그램에서 중요 함). 두 가지 경로가 있다고 생각합니다.

(1) mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) 하지만 메서드를 오버로드 할 때 α 및 β 인수는 Diagonal 허용해야합니다. 최종 사용자 코드가 여전히 스칼라 값을 통해 호출 할 수 있도록 호출 경로를 정의하는 것은 쉽습니다. 그러나 이것이 효율적으로 작동하려면 Diagonal(fill(λ, n)) https://github.com/JuliaLang/julia/pull/30298#discussion_r239845163 의 "O (1) 버전"이 LinearAlgebra에서 구현되어야합니다. 스칼라 및 대각 α 대한 구현은 크게 다르지 않습니다. 종종 α 및 α.diag[i] 교환합니다. 그래서 나는 그것이 패키지 작성자에게 큰 부담이라고 생각하지 않습니다.

이제 A 가 행렬의 행렬이고 α 가 A 때 mul!(Y, α * I, A, B) 호출 할 수 있기 때문에 위에서 언급 한 모호함이 해결되었습니다 eltype / A

(2) 위의 경로 (1)가 여전히 너무 복잡할까요? 그렇다면 지금은 muladd! 대신 사용하세요. mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) 를 지원하려는 경우 이전 버전과의 호환성을 유지하면서 마이그레이션하는 것은 어렵지 않습니다.

이 시점에서 저는이 일반 서명에 대해서만 작동하도록 정의 된 매우 제한적이고 특수한 matmul!(C, A, B, α, β) 를 가져서는 안되는지 궁금합니다.

matmul!(
    C :: VecOrMatT,
    A :: Matrix{T},
    B :: VecOrMatT,
    α :: Union{Bool,T} = true,
    β :: Union{Bool,T} = false,
) where {
    T <: Number,
    VecOrMatT <: VecOrMat{T},
}

또한이 서명이 작성되고 발송 될 수 있다는 것이 정말 놀랍습니다.

그것은 본질적으로 내 제안 (2)입니다. (나는 A :: Matrix{T} 가 문자 그대로 Core.Array{T,2} 의미하지 않는다고 생각합니다; 그렇지 않으면 gemm! )

나는 임시 해결책으로 만족할 것이며 내가 유지하는 패키지에서 부분적으로 지원할 수 있지만 (미해결 특성 문제로 인해 "부분적") 믹스에 다른 이름이 추가되지만 : mul! , muladd! 및 현재 matmul! .

... 누군가 "분류 인이 말한다 ..."를 게시하고 전화를 걸 시간이 아닙니까?

또한이 서명이 작성되고 발송 될 수 있다는 것이 정말 놀랍습니다.

이 서명을 정확히 mul! 메서드로 만들기위한 인수를 정확하게 전달할 수 있다는 사실이 아닙니다. 그런 다음 좀 더 일반적인 솔루션이 나올 경우에 대비하여 완전히 폐기 될 수도 있습니다.

이것을 mul! 의 메소드로 만들기

mul!(C, A, B, α, β) 가면 호환성을 깨지 않고 mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) 등으로 일반화 할 수있는 방법이 없습니다. (아마도이 ​​토론에서 영원히 자유롭기 때문에 "특징"일 것입니다 : smile :).

또한 경계 요소 유형을 Number _and_ 현재 3-arg mul! (이미 Number 요소 유형을 지원하지 않음)과의 호환성을 유지하면 중복.

mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) 이 (가) 무엇을 기대할지 모르겠습니다 ... 그래서 기능이라고 생각합니다.

충돌. 더 나은 내부 성능을 얻기 위해 어디에서나 BLAS 함수를 사용해야하는 것이 슬프다.

@StefanKarpinski 분류에서 가져올 수 있습니까?

전화에 약간의 사람들이 없으면 어떤 결과가 나올지 모르겠지만 토론 할 수 있습니다. 일반적으로 요즘에는 그렇지 않습니다. 솔직히 말해서, 저는이 토론을 어떤 종류의 해결책으로 옮기기 위해 상당한 시간과 노력을 들였고 모든 아이디어가 어떤 식 으로든 꾸준히 거부 된 것처럼 보였기 때문에이 문제에 대해 거의 확인했습니다 이 점. 누군가가 문제를 요약하고 다양한 제안이 부적절한 이유를 만들 수 있다면 생산적인 분류 논의에 도움이 될 것입니다. 그렇지 않으면 우리가 많은 것을 할 수있을 것 같지 않습니다.

합의가 없다는 것은 이것을 StdLib에 통합하기에 적절한시기가 아니라는 것을 의미한다고 생각합니다.

다운 사용자가 사용할 수있는 제안 중 하나를 구현하는 패키지 MatMul.jl이 아닌 이유는 무엇입니까? 실제로 StdLib에있는 것이 왜 그렇게 중요한지 모르겠습니다. 내가 유지하는 패키지에서 이것을 기꺼이 지원할 것입니다.

나는 gemm의 멋진 Julian 버전을 생각하고 있습니다! 그리고 gemv! 이미 SparseArrays에있는 것과 일치합니다. 위의 @andreasnoack 당 :

α , β 기본값을 사용하여 이미 mul!(C, A, B, α, β) 에 정산했다고 생각했습니다. 우리는이 버전을

줄리아 /stdlib/SparseArrays/src/linalg.jl

b8ca1a4의 32 ~ 50 행

...
일부 패키지도이 양식을 사용하고 있다고 생각하지만 내 머리 위에 어떤 패키지가 있는지 기억이 나지 않습니다.

그 제안에는 7 개의 엄지 손가락이 있고 거절은 없었습니다. 밀도가 높은 벡터 / 행렬에 대해이 함수를 구현하지 않는 이유는 무엇입니까? 가장 일반적인 사용 사례를 다루는 간단한 솔루션 이겠죠?

확인. 그래서 나는 합의가 있는지에 대한 합의도 없다고 생각합니다 : sweat_smile :

_I_ 거의 모든 [*]이이 API를 원한다고 생각했습니다. 함수 이름과 서명의 문제 일뿐입니다. 이 API가 _not_있는 것과 비교했을 때, 나는 모든 사람들이 어떤 옵션 (예 mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) , muladd!(C, A, B, α, β) , mul!(C, A, B, α, β) )에 만족한다고 생각했습니다. 누군가가 특정 API가없는 것보다 훨씬 더 나쁘다는 설득력있는 주장을 할 수 없다면, 나는 어떤 분류가 결정하든 만족할 것입니다.

@StefanKarpinski 그러나 토론이 아직 충분히 통합되지 않았다고 생각되면 triage 태그를 자유롭게 제거하십시오.

[*] 좋아요, @dlfivefifty , 현재의 3 개 인수 mul! 조차 의심 스럽습니다. 하지만 3 인수 mul! 인터페이스를 처음부터 변경해야하므로이 논의의 범위를 벗어난 방법이라고 생각했습니다 (5 인수 변형의 일부 형태로 _adding_에 대해 해석했습니다). LazyArrays.jl이 성숙 할 때까지 "충분히"작동하는 것이 필요하다고 생각합니다.

다운 사용자가 사용할 수있는 제안 중 하나를 구현하는 패키지 MatMul.jl이 아닌 이유는 무엇입니까?

@dlfivefifty 나는 LinearAlgebra.jl에있는 것이 인터페이스 함수 (오버로드 가능한 API)이기 때문에 중요하다고 생각합니다. 때문에 또한, mul!(C::AbstractMatrix, A::AbstractVecOrMat, B::AbstractVecOrMat) LinearAlgebra.jl에 구현되어, 우리가 정의 할 수 없습니다 mul! 의 측면에서 MatMul.muladd! . 물론 몇 가지 해결 방법이 있지만, 특히 "단지"이름과 서명을 결정해야한다는 점을 고려할 때 직접 구현하는 것이 훨씬 좋습니다.

밀도가 높은 벡터 / 행렬에 대해이 함수를 구현하지 않는 이유는 무엇입니까?

@chriscoey 불행히도 이것은 모든 사람이 좋아하는 유일한 것은 아닙니다 : https://github.com/JuliaLang/julia/issues/23919#issuecomment -441717678. 다음은이 옵션 및 기타 옵션에 대한 장단점에 대한 요약입니다. https://github.com/JuliaLang/julia/issues/23919#issuecomment -441865841. (다른 사람의 댓글도 참조)

분류에서 : 컴파일러 지원 및 BLAS에 대한 선택을 포함하여 일반 텐서 축소 API를 포함하는 장기 계획이 있지만 중기 적으로는 즉각적인 요구를 해결하는 API를 선택하십시오. BLAS와 일치하면 BLAS 이름을 선택하는 것이 합리적입니다.

@Keno , 일반 텐서 수축 API 및 컴파일러 지원에 대해 공유 할 수있는 정보가 있습니까? 공개적으로는 아니지만 (아직) 공유 할 흥미로운 정보가있을 수 있습니다.

API 설계가 수행되지 않은 것은 우리가 가져야한다는 일반적인 의미 일뿐입니다. 나는 당신이 이러한 것들 중 일부를 작업하고 있다는 것을 알고 있으므로 적절한 시점에서 디자인 세션을 갖는 것이 좋을 것입니다. 그러나 아직 우리가 거기에 있다고 생각하지 않습니다.

BLAS와 일치하면 BLAS 이름을 선택하는 것이 합리적입니다.

이것은 일반 선형 대수 함수 이름에 대해 지금까지 수행 한 작업과 완전히 반대입니다.

β == 0 의 제안 된 일반 버전에서 강 / 약 BLAS.gemm!(α, A, B, β, C) 무엇입니까?

BLAS 호출로 낮추면 lmul! 와 일치하지 않더라도 강력한 제로처럼 작동합니다. generic_muladd! 경우 β == 0 generic_muladd! 돌아가는 것 외에는 이것에 대한 해결책을 생각할 수 없습니다.

강함 / 약함 β == 0에 대한 계획은 무엇입니까?

https://github.com/JuliaLang/julia/issues/23919#issuecomment -430139849의 내 의견에 대해 간단히 논의되었으므로 분류에서 해당 질문을 해결하지 못했을 것입니다.

@Keno 아직 API 설계가 없었지만 "컴파일러 지원 및 BLAS에 대한 선택을 포함한 API"가 돌연변이로 정의되거나 XLA 선형 대수와 같이 변경 mul! 및 / 또는 muladd! 가 이러한 API의 일부가 될 것이라고 생각하십니까?

@andreasnoack '에 대한 핑 @Keno은에 질문이야 https://github.com/JuliaLang/julia/issues/23919#issuecomment -475534454

죄송합니다.이 문제로 돌아 오려고했지만 (특히 심사를 요청했습니다) 심사의 결정에 따라 다음 조치가 어떻게 될지 몰랐습니다.

BLAS와 일치하면 BLAS 이름을 선택하는 것이 합리적입니다.

@andreasnoack이 지적했듯이, 우리는 행렬-벡터 곱셈 등을 지원하기를 원하기 때문에 gemm! 사용할 수 없습니다.하지만이 분류 결정을 무시할 수 있습니다 (단지 "BLAS와 일치하는 경우"라고 표시됨). ; 그렇지 않습니다).

당장 필요한 API를 선택하면됩니다.

그래서 우리는이 방향을 따를 수 있다고 생각합니다. @StefanKarpinski가 제안한 튜플 기반 API를 잊어 버리고 mul! / muladd! / addmul! 중 하나를 "그냥"선택하는 것을 의미한다고 생각합니다.

원래 토론으로 돌아가겠습니다. 하지만 API에 대해 더 이상 논의하지 않을 제약이 있다는 것이 좋은 것 같습니다.

mul! / muladd! / addmul! 에서 이름을 고르는 방법을 아십니까?

@chriscoey 나는 미래의 API를 다른 곳에서 논의하는 것이 더 낫다고 생각합니다. 이 문제는 이미 매우 길고 중기 해결에 집중하지 않으면 진전을 이룰 수 없습니다. 새로운 이슈 (또는 담화 스레드)를 여는 것은 어떻습니까?

지금부터 10 일의 기한을두고 단일 승인 투표를 제안합니다. 승인 투표는 다음을 의미합니다. 모든 사람이 토론을 계속하는 것보다 선호되는 모든 옵션에 투표합니다. 계속되는 토론보다 지금 가장 선호하지 않는 이름을 갖고 싶은 사람들은 세 가지 모두에 투표해야합니다. 옵션이 광범위한 승인을받지 못하거나 투표 계획 자체가 광범위한 승인을 충족하지 못하는 경우 논의를 계속해야합니다. 승인 된 옵션이 거의 같은 경우 @tkf 가 결정합니다 (PR 작성자의 권한).

+1 :이 투표 계획에 동의하며 승인 투표를했습니다.
-1 :이 투표 방식에 동의하지 않습니다. 너무 많거나 너무 중요한 사람들이이 옵션을 선택하면 투표는 의문의 여지가 있습니다.

Heart : mul! 가 계속 토론하는 것보다 낫습니다.
로켓 : muladd! 이 계속되는 토론보다 낫습니다.
만세 : addmul! 이 계속 토론하는 것보다 낫습니다.

나는 75 %의 승인과 5 명이 반드시 정족수를 만들어야한다고 잠정적으로 제안합니다 (즉, 전체 투표 절차에 대한 의견 불일치를 포함하여 전혀 투표 한 사람의 75 %, 우승 옵션에 대해 최소 5 명이 승인 한 경우, 참여도가 낮은 경우) , 5/6 또는 6/8은 쿼럼을 만들지 만 만장일치의 4/4는 실패로 간주 될 수 있습니다.)

1.3 기능 동결은 8 월 15 일경입니다 : https://discourse.julialang.org/t/release-1-3-branch-date-approaching-aug-15/27233?u=chriscoey. 그때까지 병합 할 수 있기를 바랍니다 😃. 이미 투표 해 주신 모든 분들께 감사드립니다!

또한 이름을 결정하는 것과 직교하는 β == 0 https://github.com/JuliaLang/julia/issues/23919#issuecomment -475420149의 동작도 결정해야합니다. 또한 내 PR의 병합 충돌을 해결해야하며 PR은 구현 세부 사항에 대한 검토가 필요합니다 (예 : 대상 배열에서 undef s를 처리하는 데 사용한 접근 방식). 검토 중에 다른 문제를 발견 할 수 있습니다. 그래서 1.3에 들어갈 수 있을지 모르겠습니다 ....

Re : β == 0 , @andreasnoack 의 댓글 https://github.com/JuliaLang/julia/issues/23919#issuecomment -430139849 (내 요약 : β == 0 -handling은 BLAS 여야합니다. -BLAS를 최대한 활용하기 위해 호환 됨)은 의미가 있습니다. 바로 아래에서 @simonbyrne 의 주장 외에 반대 의견을 찾기가 어렵습니다 ( "모든 구현에는 0을 확인하기 위해 분기가 필요합니다"). BLAS와 같은 β == 0 처리에 대한 다른 주장이 있습니까?

@simonbyrne 귀하의 의견 https://github.com/JuliaLang/julia/issues/23919#issuecomment -430375349 와 관련하여, 명시 적 분기는 대부분 일 선형 β != 0 ? rmul!(C, β) : fill!(C, zero(eltype(C))) 이기 때문에 큰 문제라고 생각하지 않습니다. 또한 처리해야하는 매우 일반적인 구현 (예 : C = Matrix{Any}(undef, 2, 2) )의 경우 구현에는 어쨌든 명시적인 "강력한 제로"처리가 필요합니다 (내 PR https : // github의 도우미 함수 _modify! . .com / JuliaLang / julia / pull / 29634 / files # diff-e5541a621163d78812e05b4ec9c33ef4R37). 그래서 저는 BLAS와 같은 핸들링이 여기서 최선의 선택이라고 생각합니다. 어떻게 생각해?

고성능 약한 제로를 가질 수 있습니까? 우리가 원하는 의미에서 :

julia> A = [NaN 0;
                     1 0]

julia> b = [0.0,0];

julia> 0.0*A*b
2-element Array{Float64,1}:
 NaN  
   0.0

julia> false*A*b
2-element Array{Float64,1}:
 0.0
 0.0

즉, BLAS (강력 0 사용)로 낮추면 NaN 가 될 행을 수동으로 결정해야합니다.

@dlfivefifty BLAS가 A 및 B 에서 NaN을 처리 할 수 ​​있다고 생각하지만 C 없습니까?

BLAS.gemm! 등을 사용하여 NaN 인식 _C = α * A * B + 0 * C_를 효율적으로 수행 할 수있는 방법이 없다고 생각합니다. [1] @andreasnoack 의 인수가 나오는 곳입니다.

[1] isnan.(C) 어딘가에 저장하고 나중에 C "오염"시켜야합니다.

@chethega 투표 후 10 일이

@chriscoey 당신이 맞아, 투표가 마감되었습니다.

나는 투표 한 사람들의 전체 목록을 얻기에는 github에 너무 나쁩니다. 그러나 수치를 살펴보면 mul! 가 압도적 인지지를 받고 (아마 75 % 승인 쿼럼을 관리하고 있음) 두 번째 경쟁자 muladd! 가 50 %보다 훨씬 낮다는 것이 분명해 보입니다.

투표 계획에 대한 이의는 단 한 건도 없었습니다. 나는 투표를 부르고, mul! 가 이기고 이름이 결정됩니다. @tkf 는

@chethega 감사합니다, 이것을 결정하는 좋은 계획이었습니다!

BTW, 즉시 리베이스를 수행 할 수는 없지만 (몇 주 내에) 누군가 리베이스 또는 재 구현을 원하는 경우 나를 기다리지 마십시오.

안타깝게도 NaN 의미론에 대한 투표가 없었습니다. 기능 동결은 다음 주이며 의미있는 투표를 할 시간이 충분하지 않습니다.

나는 우리 가 스레드의 분위기에 대한 스냅 샷을 수집하는

다음 옵션이 표시됩니다.

1. 계속 논의하고, 기한 전에 합의가 이루어지기를 바라거나, 핵심 사람들이 우리에게 연장을 허락 해주길 바랍니다. : tada : (명확하게 편집 : 이것은 기본 옵션입니다. 즉, 다른 옵션에 대한 합의에 도달 할 수없는 경우 발생합니다. 가장 가능성이 높은 결과는 5-arg mul! 가 1.4까지 지연되는 것입니다.)
2. 정의되지 않은 NaN 동작을 백스톱으로 사용하여 새 기능을 병합합니다. 합의에 도달하자마자 코드 및 / 또는 문서를 업데이트하여 결정된 NaN 동작 (강한 0과 약한 0)을 얻습니다. 정의되지 않은 구현 정의 NaN 동작의 백스톱은 무기한으로 끝날 수 있지만 오늘은 투표 할 수 없습니다. (가장 빠른 것을 구현하십시오. 관심있는 사용자는 다른 메소드를 호출해야합니다). : 좋아요 :
3. Gemm은 Gemm을 의미합니다! 강력한 제로에 대한 문서화 된 약속으로 1.3을 병합합니다. :심장:
4. NaN 는 NaN ! 약한 0에 대한 문서화 된 약속으로 1.3을 병합합니다. : 눈 :
5. 1.3 절벽에 부딪히기 전에 무엇이든하세요. :로켓:
6. 설문 조사를 거부하십시오. : thumbsdown :
7. 쓰기
8. 제안 된 다운 스레드 : 대체 백스톱 배열. 나중에 더 고려 된 결정에 도달 할 수있을 때까지 빠르게 병합하고 1.3 알파에 대해 약한 / 강한 제로 발산을 오류로 만듭니다. 즉, !(alpha === false) && iszero(alpha) && !all(isfinite, C) && throw(ArgumentError()) 와 병합하고이 오류 검사가 다른 것을 위해 폐기 될 가능성이 있음을 문서화합니다. : 혼란 :

모순 될 수있는 여러 옵션을 자유롭게 선택하고 @tkf / triage 설문 조사를 무시

편집 : 현재 : tada : (인내)와 : rocket : (인내)는 모순되지만 둘 다 다른 모든 것과 호환됩니다. 명확하게 설명 된대로, 분류는 14 일 (수)과 15 일 (목) 사이에 지정되지 않은 날짜에 설문 조사 결과를 계산하고 지정되지 않은 방식으로 고려합니다. 이것은 다시 "승인 투표"를 의미합니다. 즉, 좋아하는 옵션뿐만 아니라 원하는 모든 옵션을 선택합니다. : rocket :은 : thumbsup :, : heart :, : eyes : 및 : confused :를 비 승인하지 않는 것으로 이해

"Merge for 1.3"대신 "Merge for 1.x"라면 강한 제로 (: heart :)에 투표 할 것입니다. 모든 "Merge for 1.3"이 "Merge 1.x"이면 옵션이 의미가 없습니까?

감사합니다 @chethega. @tkf 나는 정말로 새로운 mul이 필요한 위치에 있습니다! NaN 결정에 너무 신경 쓰지 않고 최대한 빨리 (성능이 손상되지 않는 한).

LazyArrays.jl을 확인하셨습니까? 참고로, 정말 멋진 융합 행렬 곱셈 지원이 있습니다. BLAS.gemm! 등은 공용 메소드이므로 안전하게 사용할 수 있습니다. https://docs.julialang.org/en/latest/stdlib/LinearAlgebra/#LinearAlgebra.BLAS.gemm!

나는 정말로 일반적인 mul이 필요합니다! 다양한 최적화 문제를 가장 효율적으로 표현하기 위해 다양한 구조화되고 희소하고 평범한 오래된 조밀 행렬을 사용하기 때문입니다. 나는 일반 성과 속도를 위해 여기에 있습니다.

내가 참조. 그리고 우리가 LazyArrays.jl에서 논의한 것을 기억했습니다. 물론 여러분은 이미 알고있었습니다.

"ASAP"와 관련하여 Julia의 4 개월 릴리스주기 는 적어도 기능이 동결되기 직전의 "병합 러시"를 피하기위한 것입니다. 나는 전에 같은 것을 시도했기 때문에 이것을 말하는 것이 불공평하다는 것을 알고 있습니다. 그러나 누군가 이것을 상기시키기 위해 이것을 언급해야한다고 생각합니다. 밝은면은 Julia가 만들기가 매우 쉽다는 것입니다. 병합 후 바로 다음 릴리스까지 사용할 수 있습니다.

편집 : 해제-> 병합

감사. 나는 기한이 도움이되는 동기가 될 수 있다는 것을 알고 있으며, 이것이 다시 낡아지는 것을 피하고 싶습니다. 그래서 마감일을 목표로 삼는 것을 제안합니다.

이 스레드에 적극적으로 에너지를 주입하는 것이 좋습니다!

나는 정말로 일반적인 mul이 필요합니다! 다양한 최적화 문제를 가장 효율적으로 표현하기 위해 다양한 구조화되고 희소하고 평범한 오래된 조밀 행렬을 사용하기 때문입니다. 나는 일반 성과 속도를 위해 여기에 있습니다.

5 개 인수 mul! 은 다양한 유형이있는 경우 제대로 작동하지 않습니다. 모호함을 피하기 위해 조합 적으로 많은 재정의가 필요합니다. 이것이 LazyArrays.jl MemoryLayout 시스템의 동기 중 하나입니다. 이러한 이유로 BandedMatrices.jl 및 BlockBandedMatrices.jl에서 "구조화 및 희소"행렬에 사용됩니다. (여기에는 banded BLAS 루틴으로 전달되는 banded 행렬의 하위 뷰도 있습니다.)

감사합니다. 다시 LazyArrays를 시도해 보겠습니다.

5-arg mul은 일반적으로 일시적인 임시 방편으로 간주되기 때문에 (LazyArrays와 같은 일부 솔루션이 2.0에서 사용될 수있을 때까지) 장기적으로 이상적이거나 완벽한 솔루션이 될 필요없이 병합하는 것을 목표로 할 수 있다고 생각합니다.

@chethega 언제 우리가 새로운 구속력없는 투표에 대한 집계를 계산해야한다고 생각하십니까?

@tkf 물론, 당신은 1.x에도 강함 / 약함 /

그러나 저는 1.4까지 기다리지 않고 5 인수 mul! 를 얻기 위해 1.3 mul! 갖고 싶어하는 사람이 꽤 많다고 생각합니다. 기한이 없다면 좀 더 기다렸다가 적절한 투표를 수행하는 방법을 생각하는 데 더 많은 시간을 할애했습니다 (투표를 위해 최소 10 일). 가장 중요한 것은 약한 / 강한 제로의 속도와 우아함에 대한 경쟁 구현을 먼저 제시하고 벤치마킹하지 않고서는 의미있는 투표를 할 수 없다는 것입니다. 나는 개인적으로 iszero(alpha) 를 먼저 확인한 다음 행렬에서 !isfinite 값을 검색 한 다음 추가 할당이있는 느린 경로를 사용하여 약한 0이 강한 0만큼 빠르게 만들어 질 수 있다고 생각합니다. 하지만 어쨌든 강력한 제로 의미론을 선호합니다.

@chethega 언제 우리가 새로운 구속력없는 투표에 대한 집계를 계산해야한다고 생각하십니까?

Triage는 1.3 알파에 대해 이번 주에 결정 (지연 / 강 / 약 / 백스톱)을해야합니다. 15 일 목요일 또는 14 일 수요일은 선별 검사를 고려하여 고려할 수있는 합리적인 옵션이라고 생각합니다. 나는 아마도 목요일에 가입 할 수 없을 것이므로 다른 누군가가 계산해야 할 것입니다.

현실적으로 여기에서 보수적이며 기한을 놓치고 토론을 계속하고 1.4를 기다려도 좋습니다.

다른 한편으로, 우리는 인식하지 못한 채 이미 합의에 도달했을 수 있습니다. @andreasnoack 은 계수가 0이면 강한 0이되어야한다는 강력한 주장을했습니다. 그는 약한 제로 지지자들을 모두 설득 할 수 있었을 것입니다. 아마도 작년에, 바람직하게는 작년에 5-arg mul!을 정말로 원하고이 작은 세부 사항에 대해 정말로 신경 쓰지 않는 대다수가있을 수 있습니다. 그럴 경우 아무도 토론을 닫고 싶어하지 않기 때문에 기능을 더 지연시키는 것이 유감입니다.

지금은 오류를 던지지 않는 이유 :

β == 0.0 && any(isnan,C) && throw(ArgumentError("use β = false"))

지금은 그냥 오류를 던지지 않는 이유

이 옵션을 설문 조사에 추가했습니다. 훌륭한 타협 아이디어!

기대치를 설정하기 위해 1.3의 기능 동결은 3 일 내에 이루어 지므로 기본적으로 제 시간에 완료 할 방법이 없습니다. 기능 동결 및 분기는 릴리스주기에서 실제로 타이밍을 제어 할 수있는 유일한 부분이기 때문에 매우 엄격합니다.

작업은 이미 https://github.com/JuliaLang/julia/pull/29634 에서 완료되었습니다. 조정하고 리베이스하면됩니다.

@tkf for # 29634 (투표에 따라 이름 바꾸기 및 0 처리 포함) 남은 작업을 나열 할 수 있습니까? 바쁘다는 것을 알고 있으므로 남은 할 일을 분할 할 수있는 방법을 찾아서 다시는 부담이 가지 않도록 할 수 있습니다.

ATM에 대해 생각할 수있는 TODO는 다음과 같습니다.

• 리베이스
• addmul! -> mul! 이름 바꾸기
  
  
  
  • 새 API가 mul! (예 : <strong i="15">@deprecate</strong> mul!(C, A, B, α, β) addmul!(C, A, B, α, β) )로 호출되지 않는다고 가정하여 코드를 조정합니다.
  
  
• MulAddMul 등의 구현 전략에 대해 핵심 개발자로부터 확인을받습니다. https://github.com/JuliaLang/julia/pull/29634#issuecomment -440510551을 참조 @andreasnoack , 그것을 볼 기회가 있었습니까?
• Quaternion 사용하여 테스트를 추가하는 것이 이상적입니다. https://github.com/JuliaLang/julia/pull/29634#issuecomment -443379914 참조

내 PR은 β = 0 처리의 BLAS 의미 체계를 구현합니다. 따라서 오류 발생과 같은 다른 처리도 구현해야합니다.

내 PR은 β = 0 처리의 BLAS 의미 체계를 구현합니다.

미안 해요, 제 기억은 낡았어요. 내 구현이 일관되지 않았고 NaN _ 가끔 전파됩니다 _. 따라서 추가 TODO는 β = 0.0 의 동작을 일관되게 만드는 것입니다.

MulAddMul 유형은 내부 용일 뿐이죠?

예, 그것은 완전히 내부 세부 사항입니다. 내 걱정은 (1) 너무 많은 전문화 (beta = 0 등은 type 매개 변수에 인코딩 됨)가있을 수 있고 (2) 소스 코드의 가독성을 떨어 뜨린다는 것입니다.

그것들은 타당한 우려입니다. 우리는 이미 선형 대수 코드에서 수많은 전문화를 생성하고 있으므로 여기서 전문화해야하는지 생각해 보는 것이 좋습니다. 제 생각은 일반적으로 무료가 아니기 때문에 작은 행렬을 최적화해야한다는 것입니다 (말했듯이 소스 코드를 복잡하게 만들고 컴파일 시간을 늘릴 수 있음). 사람들은 작은 행렬 곱셈에 StaticArrays 를 사용하는 것이 더 낫습니다. 따라서 저는 런타임에 값을 확인하는쪽으로 기울이지 만 마음이 바뀌면 나중에 언제든지 조정할 수 있으므로 지연이 발생하지 않도록해야합니다.

참고로 소프트 제로는 간단한 구현이 있습니다.

if iszero(β) && β !== false && !iszero(α)
   lmul!(zero(T),y) # this handles soft zeros correctly
   BLAS.gemv!(α, A, x, one(T), y) # preserves soft zeros
elseif iszero(α) && iszero(β)
   BLAS.gemv!(one(T), A, x, one(T), y) # puts NaNs in the correct place
   lmul!(zero(T), y) # everything not NaN should be zero
elseif iszero(α) && !iszero(β)
   BLAS.gemv!(one(T), A, x, β, y) # puts NaNs in the correct place
   BLAS.gemv!(-one(T), A, x, one(T), y) # subtracts out non-NaN changes
end

@andreasnoack 죄송합니다. mul!(C, A::BiTriSym, B, α, β) https://github.com/JuliaLang/julia/pull/29634#issuecomment -440510551과 같은 일부 구조화 된 행렬의 가장 안쪽 루프를 최적화하기 위해 실제로 전문화가 필요하다는 것을 잊었습니다. 일부 전문화는 제거 할 수 있지만 실제로는 더 많은 작업이 필요합니다 (따라서 지연).

따라서 저는 런타임에 값을 확인하는쪽으로 기울이지 만 마음이 바뀌면 나중에 언제든지 조정할 수 있으므로 지연이 발생하지 않도록해야합니다.

큰!

https://github.com/JuliaLang/julia/pull/29634에 의해 수정되었습니다.

@andreasnoack 제 시간에 이것을 검토하고 병합 해 주셔서 감사합니다!

이제 1.3에 병합 되었으므로 구현에 대해 매우 긴장하게됩니다.

걱정할 필요가 없습니다. 1.3 RC + PkgEvals가 버그를 제거하는 데 충분한 시간이있을 것입니다.