이전 호의 논리적 후계자 ... 👍

배열에서 요소 단위로 작동하는 conj의 동작은 Matlab의 불행한 보류이며 실제로 수학적으로 정당한 작업이 아닙니다.

이것은 전혀 사실이 아니며 exp 와 전혀 유사하지 않습니다. 복잡한 벡터 공간과 그 활용은 완벽하게 확립 된 수학적 개념입니다. https://github.com/JuliaLang/julia/pull/19996#issuecomment -272312876도

복잡한 벡터 공간과 그 활용은 완벽하게 확립 된 수학적 개념입니다.

내가 착각하지 않는 한, 그 맥락에서 올바른 수학적 활용 연산은 ctranspose 아니라 conj (정확히 내 요점이었습니다).

julia> v = rand(3) + rand(3)*im
3-element Array{Complex{Float64},1}:
 0.0647959+0.289528im
  0.420534+0.338313im
  0.690841+0.150667im

julia> v'v
0.879291582684847 + 0.0im

julia> conj(v)*v
ERROR: DimensionMismatch("Cannot multiply two vectors")
Stacktrace:
 [1] *(::Array{Complex{Float64},1}, ::Array{Complex{Float64},1}) at ./linalg/rowvector.jl:180

recur 키워드를 사용할 때의 문제점은 마지막으로 확인한 바에 따르면 키워드를 사용하면 성능이 크게 저하됩니다. 이는 결국 기본 케이스로 이러한 함수를 재귀 적으로 호출하는 경우 문제입니다. 스칼라.

어쨌든 1.0에서 키워드 실적 문제를 수정해야합니다.

@StefanKarpinski , 당신은 착각입니다. adjoint없이 벡터 공간에서 복잡한 conjugation을 가질 수 있습니다. adjoint는 복잡한 벡터 공간이 아닌 힐베르트 공간 등을 필요로하는 개념입니다.

또한 Hilbert 공간이 있더라도 복합 켤레는 인접과 구별됩니다. 예를 들어 ℂⁿ에있는 복소 열 벡터의 켤레는 또 다른 복소 벡터이지만 adjoint는 선형 연산자 ( "행 벡터")입니다.

(복잡한 활용은 conj(v)*v 곱할 수 있음을 의미하지 않습니다 !)

벡터화 된 conj 중단은 나머지 제안과 무관합니다. 벡터 공간에서 복잡한 켤레의 정의에 대한 몇 가지 참조를 제공 할 수 있습니까?

https://en.wikipedia.org/wiki/Complexification#Complex_conjugation

(이 치료법은 다소 공식적이지만 "복합 켤레 행렬"또는 "복합 켤레 벡터"를 검색하면 수많은 용도를 찾을 수 있습니다.)

복합 벡터를 켤레 벡터에 매핑하는 것이 (지금 conj 가하는 일) 켤레 코 벡터 ( ' 가하는 일)와 다른 중요한 작업이라면 확실히 conj 유지할 수 있습니다 conj 와 adjoint 는 스칼라에서는 동의하지만 배열에서는 다르게 동작하기 때문에 구별됩니다.

이 경우 conj(A) conj 는 각 요소에 대해 adjoint 호출해야합니까? 복소수를 2x2 행렬 예제로 표현하면 conj(A) 는 conj 호출하는 대신 실제로 각 요소에서 adjoint 를 호출해야 함을 알 수 있습니다. 그러면 adjoint , conj 및 conj. 모든 다른 작업이 수행됩니다.

1. adjoint : i 및 j 인덱스를 교체하고 요소에 대해 adjoint 을 재귀 적으로 매핑합니다.
2. conj : 요소 위에 adjoint 매핑.
3. conj. : 요소 위에 conj 매핑합니다.

conj(A) 는 각 요소에서 conj 를 호출해야합니다. 2x2 행렬로 복소수를 표현하는 경우 복잡한 벡터 공간이 다릅니다.

예를 들어, 벡터 접합의 일반적인 사용은 실수 행렬의 고유 값 분석에 있습니다. 고유 값 과 고유 벡터 는 복소 접합 쌍으로 제공됩니다. 이제 2 차원 배열로 표현되는 블록 행렬이 A 이고, 2 성분 벡터의 1 차원 배열로 표현되는 차단 벡터 v 에 작용한다고 가정합니다. 에 대한 고유 λ 의 A 고유 벡터와 v , 우리가 기대하는 두 번째 고유치 conj(λ) 고유 벡터와 conj(v) . conj adjoint 재귀 적으로 호출하면 작동하지 않습니다.

(행렬의 경우에도 adjoint는 conjugate-transpose와 다를 수 있습니다. 왜냐하면 가장 일반적인 방식으로 정의 된 선형 연산자 의 Matrix 가 주어지면 다음과 같이 주어진 표준 내부 곱에 해당하는 adjoint를 취해야한다는 데 동의합니다. dot(::Vector,::Vector) . 그러나 일부 AbstractMatrix (또는 기타 선형 연산자) 유형이 adjoint 를 재정 의하여 다른 작업을 수행 할 수도 있습니다.)

따라서 3d 배열을 선형 연산자로 정의하지 않았기 때문에 대수적으로 합리적인 adjoint(A) 를 정의하는 데 어려움이 있습니다 (예 : 내장 된 array3d * array2d 연산이 없음). . adjoint 는 기본적으로 스칼라, 1d 및 2d 배열에만 정의되어야합니까?

업데이트 : 오, 좋아요 : 3D 배열에 대해서도 ctranspose 정의하지 않습니다. 계속해.

(OT : 저는 이미 성공한 6 부작 미니 시리즈의 다음 편인 "7- 텐서 진지하게 받아들이 기"를 고대하고 있습니다 ...)

2x2 행렬로 복소수를 표현하는 경우 복잡한 벡터 공간이 다릅니다.

나는 이것을 따르지 않는다 – 복소수의 2x2 행렬 표현은 복잡한 스칼라를 요소로 갖는 것과 똑같이 동작해야한다. 예를 들어 우리가 정의한다면

m(z::Complex) = [z.re -z.im; z.im z.re]

그리고 우리는 임의의 복잡한 벡터 v 를 가지고 있다면이 신원이 유지되기를 원합니다 :

conj(m.(v)) == m.(conj(v))

예를 더 자세히 설명하고 이미 m 와 (과) 통근 해야하는 ' 와 (과) 비교하지만 https://github.com/JuliaLang/julia/ 때문에 할 수 없습니다. m.(v)' == m.(v') 가 유지되지만 @stevengj 라고 올바르게 이해한다면 conj(m.(v)) == m.(conj(v)) 는 안되나요 ?

conj(m(z)) 는 == m(z) 이어야합니다.

m(z) 는 덧셈과 곱셈에서 복소수에 대한 동형이지만 선형 대수에서는 다른 방식으로 동일한 객체가 아니므로 conj 척해서는 안됩니다. 예를 들어 z 이 복소수 스칼라 인 경우 eigvals(z) == [z] 이지만 eigvals(m(z)) == [z, conj(z)] 입니다. m(z) 트릭이 복잡한 행렬로 확장 될 때, 스펙트럼의 배가는 예를 들어 반복적 인 방법에 대해 까다로운 결과를 가져옵니다 (예 : 이 문서 참조).

또 다른 방법은 z 은 이미 복소수 벡터 공간 (복소수 위의 벡터 공간)이지만 2x2 실수 행렬 m(z) 는 실수 위의 벡터 공간입니다 ( 곱셈 수 m(z) 실수로) ... 당신은 "complexify"경우 m(z) 예를 들어 복소수 곱하여 m(z) * (2+3im) (안 m(z) * m(2+3im) ) 다음을 더 이상 원래의 복잡한 벡터 공간 z 동형이 아닌 다른 복잡한 벡터 공간을 얻습니다.

이 제안은 실제적인 개선을 가져올 것 같습니다. + 1 : 수학적 측면에 대해 생각하고 있습니다.

• 내가 이해했듯이 활용은 벡터 공간 / 벡터에 대한 계수를 제공하는 링 (숫자 읽기)에 대한 작업입니다. 이 동작은 벡터 공간에 대한 벡터 공간 구성의 선형성에 의해 결합이라고도하는 벡터 공간 (및 매핑, 읽기 : 행렬)에 대한 또 다른 동작을 유도합니다. 따라서 켤레는 반드시 계수에 요소별로 적용하여 작동합니다. Julia에게 이는 v , conj(v) = conj.(v) 벡터에 대한 핵심을 의미하며, conj 에 배열에 대한 메서드가 있는지 또는 스칼라에 대해서만 메서드가 있는지 여부는 디자인 선택입니다. 괜찮아 보여? (복소수 -as-2x2- 행렬 예제에 대한 스티븐의 요점은 이것이 계수가 공식적으로 / 실제로 실수 인 벡터 공간이므로 여기에서는 켤레가 효과가 없다는 것입니다.)
• adjoint 은 선형 대수를 밀접하게 포함하는 많은 중요한 영역에서 기본이되는 대수적 의미를 가지고 있습니다 (물리학에서 큰 응용 프로그램과 함께 모두 1 과 2 및 3 참조). adjoint 가 추가되면 고려중인 작업 에 대한 키워드 인수를 허용해야합니다. 벡터 공간 / 기능 분석에서이 작업은 일반적으로 내부 곱에 의해 유도되므로 대신 키워드 인수가 형식이 될 수 있습니다. Julia의 조옮김을 위해 설계된 것이 무엇이든 이러한 응용 프로그램과의 충돌을 피해야합니다. 그래서 adjoint 는 약간 높은

@felixrehren , 키워드 인수를 사용하여 adjoint를 유도하는 내부 제품을 지정하지 않을 것이라고 생각합니다. 벡터에 대해 dot 의 의미를 변경하려는 경우와 마찬가지로 다른 유형을 대신 사용하는 것이 좋습니다.

내 선호도는 조금 더 간단합니다.

• conj 그대로 (요소 별) 유지합니다.
• a' 를 adjoint(a) a' 해당하도록 만들고 항상 재귀 적으로 만듭니다 (따라서 adjoint 가 요소에 대해 정의되지 않은 문자열 배열 등에서는 실패합니다).
• a.' 를 transpose(a) 에 대응시키고 절대 재귀 적이 지 않게 만들고 (단지 permutedims ), 따라서 요소의 유형을 무시하십시오.

비 재귀 adjoint 대한 사용 사례가 실제로 보이지 않습니다. 스트레칭으로 재귀 transpose 대한 사용 사례를 상상할 수 있지만 a.' 을 transpose(a, recur=true) 로 변경해야하는 모든 응용 프로그램에서 다른 함수 transposerecursive(a) 호출하십시오. 우리는 Base에서 transposerecursive 를 정의 할 수 있지만, 이것이 실제로 필요한지 기다려야 할 정도로 드물다고 생각합니다.

저는 개인적으로 이것을 단순하게 유지하는 것이 사용자 (및 구현)에게 가장 간단하고 선형 대수 측면에서 여전히 방어 할 수 있다고 생각합니다.

지금까지 (대부분의) 선형 대수 루틴은 표준 배열 구조와 표준 내부 곱에 상당히 뿌리를두고 있습니다. 행렬이나 벡터의 각 슬롯에 "필드"의 요소를 넣습니다. 필드 요소의 경우 + , * 등 및 conj 에는 신경 쓰지만 transpose 는 신경 쓰지 않습니다 . 당신의 필드는 2 × 실제 매트릭스처럼 조금 보이지만에서 변경하는 특별한 복잡한 표현 인 경우 conj 가의 속성이다 -의 OK 것을 다음, conj . conj 아래에서 변경되지 않는 2x2 실제 AbstractMatrix 일 경우, 행렬의 그러한 요소는 adjoint 아래에서 변경 되지 않아야합니다 ( @stevengj 는 설명 할 수있는 것보다

어쨌든, 2x2 복잡한 예제는 나에게 약간의 붉은 청어를 느낍니다. 재귀 행렬 동작의 실제 원인은 블록 행렬에서 선형 대수를 수행하는 지름길이었습니다. 이 특별한 경우를 적절하게 관리하고 기본 시스템을 단순화하지 않는 이유는 무엇입니까?

그래서 내 "간단한"제안은 다음과 같습니다.

• conj 그대로 유지 (또는 AbstractArray s에 대한보기로 설정)
• a' 를 (a')[i,j] == conj(a[j,i]) 와 같은 비재 귀적 뷰로 만듭니다.
• a.' 를 (a.')[i,j] == a[j,i] 와 같은 비재 귀적 뷰로 만듭니다.
• 블록 행렬 등을 처리하기 위해 BlockArray 유형을 도입하십시오 ( Base 에서 또는 잘 지원되는 패키지에서). 이 목적을 위해 Matrix{Matrix} 보다 훨씬 강력하고 유연하지만 똑같이 효율적입니다.

이러한 규칙은 사용자가 수용하고 구축 할 수있을만큼 간단 할 것이라고 생각합니다.

추신- @StefanKarpinski 실용적인 이유로 재귀에 대한 부울 키워드 인수는 전치에 대한 뷰와 함께 작동하지 않습니다. 뷰 유형은 부울 값에 따라 달라질 수 있습니다.

또한 다른 곳에서 언급했지만 완전성을 위해 여기에 추가하겠습니다. 재귀 전치 뷰에는 래핑하는 배열과 비교하여 요소 유형이 변경 될 수 있다는 성가신 속성이 있습니다. 예 : transpose(Vector{Vector}) -> RowVector{RowVector} . 런타임 패널티없이 RowVector 대해이 요소 유형을 가져 오거나 추론을 호출하여 출력 유형을 계산하는 방법을 생각하지 못했습니다. 현재 동작 (추론 호출)이 언어 관점에서 바람직하지 않다고 생각합니다.

주의 : 사용자가 conj 를 정의하여 다른 유형을 반환하는 것을 막을 수있는 방법도 없습니다. 따라서 ConjArray 뷰는 전치가 재귀 적이든 아니든이 문제를 겪습니다.

@stevengj – "복잡한"2x2 행렬이 복잡한 벡터 공간이 아니라 공식적으로 실제 벡터 공간이라는 점을 지적하는 것은 나에게 의미가 있지만, 그 점은 재귀 적 인접에 대한 원래의 동기가 무엇인지 의문을 불러 @andyferris 의 제안은 더 좋지 않을 것입니다 (비 재귀 전치 및 인접). 복잡한 2x2 예제와 블록 행렬 표현 "원한다"가 재귀 적이기를 원한다는 사실은 암시 적이지만 첫 번째 예제에 대한 귀하의 의견을 감안할 때 비재 귀적 인접하는 다른 경우가 없는지 궁금합니다. 더 정확하고 편리합니다.

adjoint가 재귀 적이 지 않으면 adjoint가 아닙니다. 그건 틀렸어요.

잠시 시간을내어 이에 대한 정당성을 조금 더 말씀해 주시겠습니까?

벡터의 adjoint는 벡터를 스칼라에 매핑하는 선형 연산자 여야합니다. 즉, a'*a a 가 벡터 인 경우 a'*a 는 스칼라 여야합니다. 그리고 이것은 정의 속성이 a'*A*a == (A'*a)'*a 이므로 행렬에 대응하는 adjoint를 유도합니다.

a 이 벡터로 구성된 벡터 인 경우 이는 a' == adjoint(a) 이 재귀 적이어야 함을 의미합니다.

좋아, 나는 이것을 따르는 것 같다.

재귀 적 내부 제품도 있습니다.

julia> norm([[3,4]])
5.0

julia> dot([[3,4]], [[3,4]])
25

분명히 "adjoint"또는 "dual"또는 유사하게 재귀 적이어야합니다.

나는 우리가해야 할, 중앙 문제는 다음 생각 a' * b == dot(a,b) 모든 벡터에 대한 a , b ?

대안은 ' 가 반드시 adjoint를 반환하는 것이 아니라 요소를 전치하고 conj 통해 전달하는 배열 연산 일 뿐이라고 말하는 것입니다. 이것은 실제 또는 복잡한 요소에 대한 인접 요소 일뿐입니다.

선형 대수에서 adjoint에 대한 특별한 이름과 특수 기호가있는 유일한 이유는 내적과의 관계입니다. 이것이 "conjugate transpose"가 중요한 작업이고 "conjugate rotation of matrix by 90도"가 아닌 이유입니다. 무언가를 가진 아무 소용 없다 "단지 배열 작업은 스왑 행과 열 및 접합체"이 점 제품에 연결되어 있지 않은 경우.

transpose 와 비공 액 "내적"사이의 유사한 관계를 정의 할 수 있습니다. 그러나 실제로 내적이 아닌 복잡한 데이터에 대한 결합되지 않은 "내적"은 실제 내적만큼 자주 나타나지 않습니다. 연산자가 복잡한 형태로 작성 될 때 쌍 직교 관계에서 발생합니다. 대칭 (Hermitian이 아님) 형식 — 내장 Julia 함수 나 선형 대수학의 공통 용어조차없는 반면 임의의 비 숫자 배열의 행과 열을 바꾸려는 것은 특히 방송에서 훨씬 더 일반적으로 보입니다. 내가 만드는 지원할 수있는 이유입니다 transpose 남기면서 비 재귀를 adjoint 재귀.

내가 참조. 따라서 ' 을 adjoint 변경하면 conj ∘ transpose 가 아님을 분명히 알 수 있습니다.

재귀 배열과 항상 나를 혼동하는 것은 다음과 같습니다.이 컨텍스트에서 스칼라는 무엇입니까? 내가 아는 모든 경우에 벡터의 요소 는 스칼라라고합니다. 수학자가 약간의 종이에 블록-벡터 / 행렬 구조를 작성하는 경우에도 이것이 요소가 실수이거나 복소수 일 가능성이있는 더 큰 벡터 / 행렬 (즉, BlockArray ). 스칼라가 * 미만으로 곱할 수있을 것으로 예상하고 스칼라 유형 은 일반적으로 벡터간에 다르지 않으며 이중입니다.

@andyferris , 일반적인 벡터 공간 의 경우 스칼라는 벡터에 곱할 수있는 고리 (숫자)입니다. 3 * [[1,2], [3,4]] 할 수 있지만 [3,3] * [[1,2], [3,4]] 할 수는 없습니다. 따라서 Array{Array{Number}} 경우에도 올바른 스칼라 유형은 Number 입니다.

동의합니다. 그러나 요소 는 일반적으로 (동일한) 스칼라라고합니다.

어쨌든 내가 본 치료법은 링으로 시작하여 벡터 공간을 구축합니다. 링은 + , * 을 지원하지만 adjoint , dot 등을 지원하는 데 필요한 치료법을 보지 못했습니다.

(죄송합니다, 저는 우리가 모델링하는 기본 수학적 객체를 이해하려고 노력하고 있습니다).

"속기"의 의미와 "요소"의 의미에 따라 다릅니다.

예를 들어, 유한 크기의 함수 벡터와 무한 차원 연산자의 '행렬'을 갖는 것은 매우 일반적입니다. 예를 들어 거시적 맥스웰 방정식 의 다음 형식을 고려하십시오.

이 경우 "요소"가 3 성분 벡터 필드 인 2 성분 벡터에 작용하는 선형 연산자 (예 : 컬)의 2x2 행렬이 있습니다. 이들은 복소수의 스칼라 필드에 대한 벡터입니다. 어떤 의미에서 충분히 드릴 다운하면 벡터의 "요소"는 복소수 (공간의 개별 지점에있는 필드의 개별 구성 요소)이지만 다소 모호합니다.

아니면 더 정확하게는 벡터의 계수를 어떤 기준으로 설명하기 위해 항상 링을 사용할 수 없습니까?

어쨌든 결과는 여전히 adjoint가 재귀 적이어야한다는 것입니다. 나는 당신이 어떤 지점에 도달하고 있는지 이해하지 못합니다.

(객체 또는 배열의 요소는 SymPy 또는 추상적 인 수학적 객체를 나타내는 다른 데이터 구조가 될 수 있고, 곱셈이 계산 될 때 다른 객체를 반환 할 수 있으므로 예를 들어 적분.)

나는 특정 요점을 만드는 것이 아니라 더 잘 이해하려고 노력하고 있습니다. :)

확실히 위의 adjoint는 재귀 적입니다. 위의 예에서 [E, H] 를 (무한으로?) 많은 요소가 복잡한 BlockVector 또는 요소가 벡터 필드 인 2- 벡터로 생각하는 것이 가장 좋은지 궁금합니다. 이 경우 BlockVector 접근 방식은 작동하지 않을 것이라고 생각합니다.

어쨌든 고마워.

그래서 아마도 나는 다음과 같은 형태로 내 생각을 추출 할 수 있습니다.

벡터 v 경우 length(v) 는 벡터 공간의 차원, 즉 벡터 공간의 요소를 (완전히) 설명하는 데 필요한 스칼라 계수의 수를 설명합니다. 또한 v[i] 는 i 번째 스칼라 계수를 반환합니다. 지금까지 저는 AbstractVector 를 "추상 벡터"로 생각하지 않았습니다. 오히려 프로그래머가 알고있는 몇 가지 기초가 주어지면 일부 벡터 공간의 요소 계수를 보유하는 객체입니다.

간단하고 유용한 멘탈 모델처럼 보였지만 아마도 너무 제한적이고 비현실적 일 것입니다.

(편집 : Vector{T} 에서 T 에서 선형 대수 연산이 작동하려면 스칼라처럼 동작해야하기 때문에 제한적입니다.)

하지만 [3,3] * [[1,2], [3,4]] 할 수 없습니다

우리는 그것을 고칠 수 있습니다. 그것이 좋은 생각인지 아닌지는 확실하지 않지만 확실히 작동하도록 만들 수 있습니다.

나는 그것이 바람직한 지 확신하지 못한다.이 경우 [3,3] 실제로 스칼라가 아니다. (우리는 이미 [3,3]' * [[1,2], [3,4]] 를 할 수있는 능력을 가지고 있습니다-저는 선형 대수적 의미로 해석하는 방법을 정말로 모릅니다).

이것은 흥미로운 코너 케이스를 보여줍니다. 우리는 v1' * v2 가 내부 곱 (따라서 "스칼라"를 반환)이라고 말하는 것처럼 보이지만 [3,3]' * [[1,2], [3,4]] == [12, 18] 입니다. 인위적인 예라고 생각합니다.

이 경우 [3,3] 는 스칼라입니다. 스칼라는 기본 링의 요소이며 [a,b] 형식의 요소를 링으로 만드는 좋은 방법이 많이 있습니다 (따라서 벡터 / 행렬 정의 그 위에). 그것들이 벡터로 쓰여졌다는 사실 또는이 고리 자체가 다른 기본 고리 위에 벡터 공간을 형성한다는 사실은 그것을 바꾸지 않습니다. (벡터를 숨길 수있는 다른 표기법을 사용할 수도 있습니다! 아니면 완전히 다르게 보이게 만들 수도 있습니다.) @andyferris 가 살펴본 것처럼 스칼라는 컨텍스트에 따라 다릅니다.

공식적으로 재귀는 adjoint의 일부가 아닙니다. 대신 스칼라 요소의 결합은 작품의 일부는 않습니다 - 그리고 종종 스칼라 경우 s 활용시키는, 매트릭스로 표현 s 우리가 나타내는 데 사용하는 행렬을 전치 포함 할 것이다 그것. 그러나 항상 그런 것은 아니며 사용자가 스칼라 링에 대해 부여한 구조에 따라 다릅니다.

나는 adjoint recursion을 강제하는 것이 matlab 유형 응용 프로그램에 일반적으로 사용되는 실질적인 타협이 될 수 있다고 생각합니다. 그러나 나를 위해 그것을 매우 심각하게 받아들이는 것은 비재 귀적 인접을 의미하고 유형이 지정된 스칼라 + 디스패치를 ​​사용하여 conj 가 기본 링의 구조가 무엇이든 필요한 마법을 작동하도록합니다.

이 경우 [3,3]은 스칼라입니다. 스칼라는 기본 링의 요소입니다.

이러한 스칼라는 + , * 정의 된 링의 요소가 아니라는 점을 제외하고는. * 지원하지 않습니다. [3,3] * [3,3] 할 수 없습니다.

나는 adjoint recursion을 강제하는 것이 matlab 유형 응용 프로그램에 일반적으로 사용되는 실질적인 타협이 될 수 있다고 생각합니다. 그러나 나를 위해 그것을 매우 심각하게 받아들이는 것은 비재 귀적 인접을 의미하고 유형이 지정된 스칼라 + 디스패치를 ​​사용하여 conj 가 기본 링의 구조가 무엇이든 필요한 마법을 작동하도록합니다.

저는 동의합니다. 실용적인 구성을하고 싶다면 이것은 완전히 괜찮습니다. 그리고 지금까지 우리가 해왔 던 것입니다.하지만 저에게는 기본 스칼라가 완전히 평탄화 된 배열의 스칼라이고 이것이 선형 대수학이 정의 된 것 같습니다. . BlockVector 및 BlockMatrix (및 BlockDiagonal 등)을 만드는 기술이있어 완전히 확장 된 배열의 효율적이고 평면화 된보기를 제공합니다. "접근 방식은 최소한 실행 가능해야합니다. 나는 또한 재귀 적 접근 방식만큼 사용자 친화적 일 것이라고 생각합니다 (더 좋은 의미와 잠재적으로 더 읽기 쉬운 코드 가 될 BlockMatrix([A B; C D]) 를 입력하는 몇 개의 추가 문자-나는 이것들을 확신합니다 논란의 여지가 있습니다). 그러나이 모든 것을 구현하려면 더 많은 작업이 필요합니다.

@andyferris 맞습니다. * 가 정의되지 않았기 때문에 반지가 아닙니다.하지만 * 쉽게 정의 할 수있는 페이지에있는 것 같습니다. 고리 구조를 만드는 방법에는 여러 가지가 있습니다. 그래서 나는 우리가 같은 페이지에 있다고 가정합니다. 타이핑은 이것을 해결하는 더 확장 가능한 방법입니다.

(스칼라 정보 : 스칼라가 반드시 완전히 평탄화 된 구조의 요소는 아닙니다 ! 이유는 이것입니다. 1 차원 복소 벡터 공간은 복소수에 대해 1 차원이고 실수에 대해 2 차원입니다. 특별합니다. 쿼터니언은 복소수보다 2 차원입니다. 옥 토니 언은 쿼터니언보다 2 차원, 복소수보다 4 차원, 실수에 대해서는 8 차원입니다.하지만 더 이상 8 차원이 "8 차원"이라고 주장 할 이유가 없습니다. 스칼라가 복잡하지 않은 실수라고 주장하는 것보다, 그것들은 논리에 의해 강제되지 않는 선택입니다. 순전히 표현의 문제이며, 선형 대수가 각각의 경우에 동일하기 때문에 사용자는 이러한 자유를 허용해야합니다. [잘린] 다중 다항식 고리 또는 숫자 필드의 대수적 확장이있는 이러한 공간의 훨씬 더 긴 체인은 둘 다 행렬을 사용하여 생동감있게 적용됩니다. Julia는 토끼 구멍 아래로 멀리 갈 필요가 없습니다. 차단하지 않도록 존재한다는 것을 기억해야합니다. 담화 주제일까요? :))

@felixrehren , 링 R 위의 벡터로 구성된 벡터는 직접 합계 공간으로 가장 잘 이해되며 R 위의 벡터 공간이기도합니다. 일반적으로 벡터 자체를 "기본 링"이라고 부르는 것은 의미가 없습니다. 반지. 그 추론은 [[1,2], [3,4]] 완벽하게 적용됩니다.

활용과 인접은 일반적으로 별개의 개념입니다. "스칼라 요소의 활용"이 여기서 작업을 수행해야한다는 말은 아래에 언급 된 특별한 경우를 제외하고는 "심각한"의 반대 인 나에게는 완전히 잘못된 것처럼 보입니다.

Dirac 표기법으로 일부 링 (복소수 ℂ) 위의 일부 힐베르트 공간 H에서 두 요소 | u⟩ 및 | v⟩의 "2 성분 열 벡터"(| u⟩, | v⟩)의 경우를 고려하십시오. "벡터의 벡터." 이것은 자연적인 내적 ⟨(| u⟩, | v⟩), (| w⟩, | z⟩)⟩ = ⟨u | w⟩ + ⟨v | z⟩를 갖는 직접 합 힐베르트 공간 H⊕H입니다. 따라서 adjoint는 요소 자체가 선형 연산자 인 "행 벡터"(⟨u | ⟨v |)로 구성된 선형 연산자를 생성해야합니다. adjoint 는 다음과 같습니다."재귀" . 이것은 밑받침 고리의 접합에 의해 유도 된 동일한 힐베르트 공간 H⊕H의 요소를 생성하는 복합 접합체와는 완전히 다릅니다.

쿼터니언 등의 벡터를 참조하여 문제를 혼동하고 있습니다. 벡터의 "요소"가 기본 "복잡한"고리의 요소 이기도 하다면, 물론 이러한 요소의 결합과 켤레는 동일합니다. 그러나 이는 모든 직접 제품 공간에 적용되는 것은 아닙니다.

다시 말해, 객체 유형은 두 가지 다른 정보를 나타내야합니다.

• 스칼라 링 (따라서 동일한 공간의 요소를 생성하는 켤레).
• 내적 (따라서 이중 공간의 요소를 생성하는 인접).

Vector{T<:Number} , 스칼라 링이 T (또는 복잡한 벡터 공간의 경우 complex(T) )이고 내부 곱이 일반적인 유클리드 곱임을 나타내는 것으로 읽어야합니다. .

벡터로 구성된 벡터가있는 경우 이는 Hilbert 공간의 정합이고 링은 개별 벡터의 스칼라 링의 승격이며 내적은 요소의 내적의 합입니다. (스칼라를 승격 할 수 없거나 내적을 합할 수없는 경우에는 벡터 / 힐버트 공간이 아닙니다.)

스칼라 T<:Number 가 있으면 conj(x::T) == adjoint(x::T) 입니다.

따라서 복소수 z::Complex{T} 를 2x2 행렬 m(z)::Array{T,2} 나타내려고하면 유형은 z 와 비교하여 다른 링 T 과 다른 내부 곱을 모두 나타냅니다. z 이므로 conj 또는 adjoint 동등한 결과를 제공 할 것으로 기 대해서는 안됩니다.

나는 당신이 @felixrehren을 말하는 것을 봅니다. 스칼라가 실수이면 옥터 니안은 8 차원 벡터 공간으로 생각할 수 있습니다. 그러나 스칼라 계수가 8 진수이면 모든 8 진수를 나타내는 사소한 차원 1 기저가 있습니다. 이것이 내가 말한 것과 다른지 (또는 내가 의미하는 바 : smile :) 확실하지 않습니다. AbstractVector{T1} 가 있다면 다른 차원의 AbstractVector{T2} 과 동형 일 수 있습니다 ( length ). 그러나 T1 및 T2 는 모두 Julia 연산자 + 및 * 아래의 링이어야합니다 (동형이 + 의 동작을 유지할 수 있음). 그러나 * 또는 내부 제품 또는 adjoint는 제외).

@stevengj 저는 항상 BlockVector 과 정확히 같은 직접 합계를 생각했습니다. 두 개의 (분리 된) 불완전한 염기가 있습니다. 각 베이시스 내에서 첫 번째 베이시스에서 c₁ | X₁⟩ + c₂ | X₂⟩ 또는 두 번째 베이시스에서 c₃ | Y₁⟩ + c₄ | Y₂⟩와 같은 중첩을 형성 할 수 있습니다. "직접 합"은 (c₁ | X₁⟩ + c₂ | X₂⟩) + (c₃ | Y₁⟩ + c₄ | Y₂⟩)와 같은 상태의 공간을 나타냅니다. 복소수 (즉, c₁ | X₁⟩ + c₂ | X₂⟩ + c₃ | Y₁⟩ + c₄ | Y₂⟩와 같은 상태)에 대한 차원 4의 기준에서 이것을 분리하는 유일한 특별한 것은 대괄호입니다. 나에게 그것은 표기법처럼 보인다. 직접 합계는이를 종이에 또는 컴퓨터의 배열로 작성하는 편리한 방법 일뿐입니다 (예를 들어 대칭을 카탈로그 화하고 활용하거나 문제를 분할 (아마도 병렬화)하는 데 유용 할 수 있습니다). ). 이 예에서 X⊕Y는 여전히 스칼라가 복잡한 4 차원 벡터 공간입니다.

이것이 내가 eltype(v) == Vector{Complex{...}} 및 length(v) == 2 대신 eltype(v) == Complex{...} 및 length(v) == 4 원하게 만드는 이유입니다. 기본 링과 벡터 공간을보고 추론하는 데 도움이됩니다. adjoint를 계산하기 위해 "전역"전치 및 요소 별 conj 를 수행 할 수있는 "평탄화 된"공간도 아닙니까?

(내가 글을 쓰는 동안 @stevengj : smile :)

물론, BlockArray 대신 중첩 배열을 직접 합계에 대한 규칙 으로 사용하는 것을 선호한다면 (지금처럼)이 방법도 훌륭하고 일관성이 있습니다! 스칼라 필드 (일종의 재귀 eltype)를 결정하고 효과적인 평면화 된 차원 (일종의 재귀 크기)을 결정하는 몇 가지 추가 함수를 통해 우리가 수행하는 선형 대수에 대해 추론하기 쉽게 만들 수 있습니다.

분명히 말하면, 저는 두 가지 접근 방식에 만족하며이 토론에서 많은 것을 배웠습니다. 감사.

@andyferris , 단지 두 개의 공간이 동형이라고해서 그것이 "동일한"공간이라는 것을 의미하지는 않으며, 그 중 어느 것이 벡터 공간이 "정말"인지 (또는 "정말"같은지 여부) 논쟁은 형이상학 적 수렁입니다. 우리는 결코 탈출하지 않을 것입니다. (그러나 무한 차원 벡터 공간의 직접 합계의 경우는 직접 합계의 "평탄화 된"개념이 "하나의 모든 요소와 다른 요소의 모든 요소"라는 한계를 보여줍니다.)

다시 말씀 드리지만, 귀하의 요점이 무엇인지 잘 모르겠습니다. Julia의 eltype(::Vector{Vector{Complex}}) 는 Complex 이어야한다고 진지하게 제안하고 있습니까? 아니면 length 가 길이의 합계를 반환해야한다고 진지하게 제안하고 있습니까? 줄리아의 모든 사람들이 직접 합계 공간에 대해 "평탄화 된"동형을 채택하도록 강요해야합니까? 그렇지 않은 경우 adjoint는 재귀 적이어야합니다.

그리고 "특정 요점을 말하지 않고 더 잘 이해하려고 노력하는 중"이라면 다른 포럼으로 이동할 수 있습니까? 이 문제는 직접 합 공간의 의미에 대한 형이상학 적 주장 없이는 충분히 혼란 스럽습니다.

두 개의 공백이 동형이라고해서 "동일한"공간이라는 의미는 아닙니다.

나는 그것을 전혀 제안하지 않았다.

다시 말하지만 당신의 요점이 무엇인지 잘 모르겠습니다.

저는 AbstractArray 선형 대수를하고 싶다면 eltype 가 링이되는 것이 더 좋습니다 ( + , * 및 conj ) 예를 들어 [1,2] * [3,4] 가 작동하지 않기 때문에 Vector eltypes를 배제합니다. 벡터의 length 는 실제로 선형 대수의 차원을 나타냅니다. 예, 이것은 무한 차원 벡터 공간을 배제하지만 일반적으로 Julia에서는 AbstractVector 크기를 무한대로 조정할 수 없습니다. 이렇게하면 Julia에서 선형 대수 기능을 구현하고 사용하는 방법을 쉽게 추론 할 수 있다고 생각합니다. 그러나 사용자는 중첩 배열 구조를 사용하는 대신 BlockArray 또는 이와 유사한 방식을 통해 직접 합계를 명시 적으로 표시해야합니다.

이것은 상당히 파괴적인 제안이며 눈에 띄는 단점이 있습니다 (여러분이 언급 한 일부). 따라서 "좋은 생각이지만 실용적이지 않을 것"이라고 말하면 불행하지 않을 것입니다. 그러나 중첩 배열 접근 방식이 기본 선형 대수에 대한 몇 가지 사항을 좀 더 불투명하게 만든다는 점도 지적하려고했습니다.

이 모든 것이 OP와 직접적으로 관련이있는 것 같습니다. 강제 편 평화 접근 방식을 사용하면 재귀 전치 / 인접을 버리고, 재귀 전치 / 인접을 버리면 선형 대수를 위해 평면화 된 구조 만 실행 가능할 수 있습니다. 평면화 된 접근 방식을 적용하지 않으면 재귀 적 인접을 유지 해야합니다 . 나에게 그것은 연결된 결정처럼 보였다.

Julia의 eltype(::Vector{Vector{Complex}}) 는 Complex 이어야한다고 진지하게 제안하고 있습니까? 아니면 length 가 길이의 합계를 반환해야한다고 진지하게 제안하고 있습니까?

아니요, 죄송합니다. 제가 작성한 내용이 명확하지 않을 수도 있습니다.이 목적을위한 두 가지 새로운 편의 기능이 특정 상황에서 유용 할 수 있다고 제안한 것뿐입니다. 예를 들어 zero 또는 one 를 원할 수도 있습니다.

줄리아의 모든 사람들이 직접 합계 공간에 대해 "평탄화 된"동형을 채택해야한다는 말입니까?

나는 그것을 가능성으로 제안 했습니다. 나는 그것이 최선의 아이디어라고 100 % 확신하지는 못하지만 몇 가지 장점 (그리고 몇 가지 단점)이 있다고 느낍니다.

여기에 실행 가능한 변경 영역을 반환하면 @stevengj 의 내 제안에 대한 단순화 된 버전이 여기로 이동하는 방법 인 것 같습니다.

• conj 그대로 (요소 별) 유지합니다.
• a' 을 adjoint(a) a' 해당하도록 만들고 항상 재귀 적으로 만듭니다 (따라서 요소에 대해 adjoint가 정의되지 않은 문자열 배열 등에서는 실패합니다).
• a.' 를 transpose(a) 에 대응시키고 절대 재귀 적이 지 않게 만들고 (단지 permutedims ), 따라서 요소의 유형을 무시하십시오.

여기에서 추출 할 수있는 주요 실제 "할 일"은 다음과 같습니다.

1. [] 바꾸기에게 ctranspose 에 adjoint .
2. [] transpose 를 비 재귀로 변경합니다.
3. [] 이것이 행 벡터와 어떻게 어울리는 지 알아 내십시오.

나는 재귀 전치에 의존하는 것이 충분히 드물 어서 1.0에서 이것을 변경하고 NEWS에서 중단으로 나열 할 수 있다고 생각합니다. ctranspose 를 adjoint 로 변경하면 일반 지원 중단을 겪을 수 있습니다 (하지만 1.0에서는이 작업을 수행함). 다른 조치가 필요합니까?

@StefanKarpinski , RowVector 해당하는 변경도해야합니다. 한 가지 가능성은 lazy non-recursive transpose 및 lazy recursive adjoint 각각에 대해 RowVector 를 Transpose 및 Adjoint 유형으로 분할하는 것입니다. Conj (게으른 conj )를 제거합니다.

적어도 접선 적으로 관련된 몇 가지 변경 사항

• transpose 및 adjoint / AbstractMatrix 대한 일부보기 유형
• 확인 adjoint(::Diagonal) 재귀 (틀림없이 우리는이 "버그"수정해야 Diagonal 에 대해 transpose 및 ctranspose 줄리아 v0.6.0 이전을)
• 다음과 같은 적절한 "스칼라"유형을 사용하십시오. v = Vector{Vector{Float64}}(); dot(v,v) (현재 오류- zero(Vector{Float64}) 반환 시도)

좋아, 나는 재귀 블록 행렬을 더 진지하게 받아들이려고 노력해 왔으며 이것을 뒷받침하기 위해 여기서 Diagonal 의 동작을 개선하려고 노력하고 있습니다 (이미 블록 대각선을 예상하는 몇 가지 방법이 있습니다 구조 (예 : getindex )이므로이 경우 전치 재귀 적으로 만드는 것이 자연스러워 보입니다).

내가 막힌 부분과 위의 모든 논의 포인트에 직접적으로 동기를 부여한 것은 inv , det , expm 포함하여 이러한 구조에서 선형 대수 연산을 수행하는 방법입니다. eig 등. 예를 들어, 모든 대각선 요소의 곱만 취하는 det(::Diagonal{T}) where T 메서드가 있습니다. T <: Number 에서 훌륭하게 작동하며 모든 요소가 동일한 크기의 정사각형 행렬 또한 재귀 전치 (편집 : adjoint)가 올바른 것입니다).

그러나 일반적인 블록 대각선 행렬 Diagonal{Matrix{T}} 또는 임의의 블록 행렬 Matrix{Matrix{T}} 를 생각하면 일반적으로 그 행렬식을 스칼라 T 로 말할 수 있습니다. 즉, 크기가 (3 ⊕ 4) × (3 ⊕ 4) (3x3, 4x4 차원의 행렬 인 대각선 요소가 있고 대각선을 벗어난 요소와 일치하는 2x2 행렬)이면 det "평탄화 된"7x7 구조의 결정 인자입니까, 아니면 단순히 2x2의 요소를 그대로 곱해야합니까 (이 경우에는 오류가 발생 함)?

(편집 : 위의 치수를 모두 다르게 변경하여 모호한 언어를 피해야 함)

나는 a' 이 재귀 적이라는 문제는 없지만 개인적으로 새로운 a.' 표기법이 매우 혼란 스럽다는 것을 알게 될 것입니다. a.' 구문을 보여 주면 Julia의 멘탈 모델을 기반으로 transpose.(a) 즉, a 의 요소 별 조옮김을 수행한다고 말씀 드리고 싶습니다. 잘못된. 또는 a' 및 a.' 가 둘 다 전치 옵션이고 둘 중 하나도 요소별로 반복된다는 것을 보여 주면 a.' 에 요소 별 재귀, 그리고 나는 다시 틀릴 것입니다.

물론, . 의미하는 바에 대한 저의 정신적 모델은이 경우에 잘못된 것입니다. 그러나 나는 그 구문을 정확하게 잘못된 방식으로 해석하는 유일한 사람이 아니라고 생각합니다. 이를 위해 비 재귀 전치에 .' 이외의 것을 사용하는 것이 좋습니다.

@rdeits 이 구문은 MATLAB에서 파생 된 것 같습니다. 이것은 (아주 멋진) dot-call 브로드 캐스트 구문이 v0.5에 도입 된 후 조금 불행 해졌습니다.

우리는 MATLAB과는 별개로 우리 자신의 길을 만들어서 이것을 바꿀 수 있습니다. 그러나 저는 그것에 대해 어딘가에 별도의 논의가 있었다고 믿습니다 (누구든지 어디에 기억합니까?).

아, 안타깝 네요. 감사!

또 다른 할 일 :

• [] transpose 및 adjoint 와 일치하도록 issymmetric 및 ishermitian adjoint – 각 쌍의 전자는 비 재귀이고 후자는 재귀입니다.

Matlab .' 구문은 새로운 . 구문의 맥락에서 확실히 매우 불행합니다. 나는 이것을 변경하는 것에 반대하지 않을 것이지만, 우리는 전치에 대한 새로운 구문이 필요하고 우리가 사용할 수 있는지 확신하지 못합니다. 누구든지 조옮김에 대한 제안이 있습니까?

전치 구문 토론을 여기로 이동해 보겠습니다 : https://github.com/JuliaLang/julia/issues/21037.

transpose / ctranspose / adjoint / A::Matrix{Matrix{T}} 블록 행렬처럼 취급하지 않습니다. @andyferris 가 적어도 부분적으로 암시하는 것처럼 보이는 게으른 hvcat 감각. 즉, A 의 요소가 모두 동일한 크기의 정사각형 행렬 (즉, 링을 형성)이면 det(A) 가 해당 크기의 정사각형을 다시 반환 할 것으로 예상합니다. 직사각형이거나 크기가 다른 경우 오류가 발생합니다.

즉, 블록 매트릭스 / 게으른 고양이 유형이 유용 할 수 있지만, 평탄화 된 데이터에 대해 작업하기 위해 예를 들어 getindex 와 같이 정의해야합니다. 하지만이 개념이 Matrix 또는 Diagonal 와 같은 기존 매트릭스 유형에 흡수되는 것을보고 싶지 않습니다.

이것은 안심입니다, @martinholters. 이 스레드의 앞부분에서 제가 당황했던 것은 Julia의 전체 선형 대수 프레임 워크를 임의의 블록 행렬 (부분 행렬의 크기가 다른)에 대해 Matrix{Matrix} 에 어떻게 든 적용 할 수 있어야한다는 생각이었습니다.

내가 함께 주장했다 "병합"요소가 무엇인지의 멋진 성찰을하고, 단지 반지의 요소로 자신의 장점의 요소를 취급하지 않습니다. 그러나 재귀 적 ctranspose / adjoint 은이를 선형 연산자처럼 작동하는 요소로 확장하여 정확하고 유용 해 보입니다. (다른 경우는 벡터처럼 작동하는 벡터의 요소이며 재귀 적 인접도 정확합니다).

조금 더 돌아가려면- transpose(x) = x 및 ctranpsose(x) = conj(x) 대한 기본 no-op 동작을 제거한 원래 동기는 무엇입니까? 이것들은 항상 나에게 매우 유용 해 보였습니다.

조금 더 돌아가려면-transpose (x) = x 및 ctranpsose (x) = conj (x)에 대한 기본 no-op 동작을 제거하는 원래 동기는 무엇입니까? 이것들은 항상 나에게 매우 유용 해 보였습니다.

이는 ctranspose 을 전문화하지 못한 커스텀 선형 연산자 유형 (AbstractArray의 하위 유형이 될 수 없음)에 의해 동기 부여되었습니다. 이것은 그들이 폴백에서 잘못된 no-op 동작을 물려 받았다는 것을 의미합니다. 우리는 폴 백이 조용히 부정확하지 않도록 디스패치를 ​​구성하려고 노력했습니다 (하지만 비관적 인 복잡성이있을 수 있음). https://github.com/JuliaLang/julia/issues/13171

https://discourse.julialang.org/t/proposal-rename-rowvector-to-transposevector-add-rowvector-that-doesnt-transposes-entries/4681

두 가지 옵션이있는 것 같습니다. 둘 다에서 transpose 는 비 재귀 적이됩니다. 그렇지 않으면 :

1. 비 재귀 ctranspose .
2. 재귀 ctranspose .

@stevengj , @jiahao , @andreasnoack – 여기서 선호하는 것은 무엇입니까? 기타?

@jiahao 의 JuliaCon 2017 토크 이후로

나에게 여전히 선형 대수는 "스칼라"필드와 관련하여 T 요소 유형으로 정의되어야한다고 생각합니다. T 가 필드 인 경우 ( + , * 및 conj ( - , / , .. .)) 그러면 Base.LinAlg 메서드가 실패해야하는 이유를 알 수 없습니다.

OTOH 예를 들어 블록 행렬의 전치에 대해 이야기하는 것은 매우 일반적이며 유효합니다. 예를 들어, "1 차"스칼라 세트, "2 차"스칼라 세트, "3 차"세트를 사용하여 세트 세트를 논의 할 때 발생하는 이상한 진술을 다루는 "수학적"유형 이론에서 배울 수 있다고 생각합니다. 주문 "스칼라 세트 세트 등이 있습니다. 배열 배열을 다룰 때도 여기에 동일한 문제 (및 기회)가 있다고 생각합니다. Julia의 유형 시스템을 사용하여 "진정한"스칼라의 "1 차"배열, 스칼라 배열의 "2 차"배열 등을 설명 할 수 있습니다. . 저는 @stevengj , 저와 다른 사람들 사이의 긴 토론이 예, 임의의 "순서"의 배열과이 프레임 워크에서 일관된 연산 집합을 생각 비롯 되었다고 생각합니다. (c) transpose는 명확하고 정확하게 재귀 적이지만 그렇게 할 필요는 없습니다. Jiahao의 강연이 명확하게 지적했듯이, 프로그래밍 언어 / 프레임 워크는 스칼라를 배열 (또는 아님)과 구별하고 벡터를 행렬 (또는 아님)과 구별하는 것에 대한 의미 론적 선택을하며, 이것이 우리가 할 수있는 관련 선택이라고 생각합니다.

나에게 중요한 점은 "임의의 순서"배열이 작동하도록하려면 일반적으로 벡터와 행렬에서만 정의되는 일부 연산을 "스칼라"에 가르쳐야한다는 것입니다. 이를 수행하는 현재 Julia 메서드는 transpose(x::Number) = x 입니다. 그러나이 방법을 제거하여 배열과 스칼라 사이의 의미 구분을 확장하는 것이 정말 더 좋을 것입니다.

다음 단계는 Base.LinAlg 에 1 차 행렬과 2 차 행렬의 차이를 가르치는 것입니다. 나는 두 가지 실행 가능한 옵션을 생각했습니다. 더 많은 것이있을 수 있습니다. 정말 모르겠습니다.

• T 이 AbstractMatOrVec 일 때 transpose(::AbstractMatrix{T}) 이 재귀 적이며 T 가 a Number , 그렇지 않으면 어떻게 든 구성 가능하게 만듭니다 (옵트 인, 옵트 아웃 등). (어떤면에서 이것은 요소에 대한 transpose 메서드의 동작을 제어하여 현재 수행되고 있지만, (outer)의 transpose 메서드 동작을 제어하는 ​​것이 더 깔끔하다고 생각합니다. ) 배열).
• 또는 Array 포함하여 대부분의 AbstractArray 가 첫 번째 순서라고 주장하고 (요소 가 스칼라 필드 임) 다른 AbstractArray 유형 (예 NestedArray )을 사용하여 배열을 래핑하고 해당 요소가 스칼라가 아닌 배열로 처리됨을 "표시"합니다. 나는 이것을 조금 가지고 놀아 보았지만 위의 옵션은 아마도 사용자에게 부담이 덜한 것 같습니다.

줄리아가 배열과 스칼라 사이에 강력한 의미 론적 분리를하고 있으며, 스칼라가 배열 속성 transpose 대해 "학습"되어야했기 때문에 현재 상황이 (나에게) 약간 일치하지 않는 것처럼 보입니다. 사용자는 Matrix{Float64} 가 스칼라 행렬 (1 차 배열)이고 Matrix{Matrix{Float64}} 가 블록 행렬 (2 차 배열)임을 명확하게 알 수 있습니다. 배열이 "첫 번째 순서"인지 여부를 결정하기 위해 유형 시스템이나 특성을 사용하는 것이 더 일관성이있을 수 있습니다. 또한 내가 나열한 첫 번째 옵션은 Julia를보다 사용자 친화적으로 만들면서 (그래서 ["abc", "def"].' 를 할 수 있음) 블록 행렬로 합리적이고 유용한 기본 작업을 수행 할 수있는 유연성을 유지할 것이라고 생각합니다.

너무 오랫동안 하프를 연주해서 미안하지만 JuliaCon 에서 @jiahao와 대화를 @StefanKarpinski가 언급 한 다른 옵션을 만들 수 있다고 확신하지만, 나에게는 RowVector 도입 전에 행렬 / 벡터 대수가 "작동"했던 것처럼 "작동"할 수 있습니다.

TLDR은-( c ) transpose 둘 다 재귀 적이든 아니든 만들지 마십시오 (즉, 구성 가능).

이것들은 좋은 점이지만 (c)transpose 재귀에 대한 거의 모든 불만이 ' 및 .' 비 수학 사용과 관련이 있다는 점을 지적하고 싶습니다 Vector{String} 및 Vector{PyObject} 를 1xn 행렬로 재구성 할 때 Vector{String} . 타입별로 수정하기는 쉽지만 성가신 것을 알 수 있습니다. 그러나 재귀 적 정의는 수학적으로 옳고 "정확하지만 많은 경우에 성가시다"는 것이 "편리하지만 드물게 잘못된 경우"보다 낫다고 생각했습니다.

가능한 해결책은 첫 번째 글 머리 기호에서 제안 할 수 있습니다. 즉, 배열과 같은 요소에 대한 재귀 전치 만 사용하는 것입니다. 나는 T<:AbstractVecOrMat 가 상태를 "편리하지만 매우 드문 경우에 잘못됨"으로 변경하는 대부분의 경우를 커버 할 것이라고 생각합니다. 여전히 잘못된 이유는 AbstractArray 인터페이스가 주로 배열 ( getindex ) 의미론에 관한 것이기 때문에 일부 연산자와 유사한 유형이 AbstractMatrix 범주에 맞지 않기 때문입니다. , 선형 대수가 아닙니다.

@andyferris , 스칼라의 adjoint 및 dual은 완벽하게 잘 정의되어 있으며 ctranspose(x::Number) = conj(x) 가 정확합니다.

내 느낌은 transpose 의 대부분의 사용이 "비 수학"이고 ctranspose 의 대부분의 사용 (즉, 활용 행동이 필요한 용도)은 수학적인 것입니다 (활용할 다른 이유가 없기 때문) ). 따라서 비 재귀 transpose 및 재귀 ctranspose 선호하는 경향이 있습니다.

개인적으로, 중첩 된 Arrays 로 블록 배열을 살펴 보려고하는 것은 여기의 이유 때문에 복잡해지며 https://github.com/KristofferC/BlockArrays.jl에 대한 전용 유형을 갖는 것이 더 좋습니다. 이.

@KristofferC 멋지네요.

@stevengj 가 위에서 AbstractArray 아닐 수 있습니다. 우리는 이것들에 대해 재귀 (c) 전치를하는 방법이 확실히 필요합니다. 당신이 이것에 대해 생각했는지 아닌지는 확실하지 않지만 나는 그것을 언급 할 것이라고 생각했습니다.

이 주제에 대한 slack / # linalg 대화의 하이라이트. 위의 스레드 중 일부를 요약합니다. 의미론에 중점을두고 철자를 피합니다. (그 대화에 참여 해주신 모든 분들께 감사드립니다! :))

의미 적으로 구별되는 세 가지 작업이 있습니다.
1) "수학적 adjoint"(재귀 및 게으른)
2) "수학적 전치"(이상적으로는 재귀적이고 게으른)
3) "구조적 전치"(이상적으로는 비 재귀적이고 "열심")

현재 상황 : permutedims(C, (2, 1)) 차원 C 경우 "mathematical adjoint"는 ctranspose 매핑되고, "mathematical transpose"는 transpose 매핑되고, "structural transpose"는 permutedims(C, (2, 1)) 에 매핑됩니다 transpose 그리고 reshape(C, 1, length(C)) 한 dimesional에 대한 C . 문제 : "구조적 전치"는 일반적인 작업이며 permutedims / reshape 스토리는 실제로 다소 혼란 스럽거나 부자연 스럽거나 짜증납니다.

발생 방법 : 이전에 "구조적 전치"는 transpose(x::Any) = x , ctranspose(x::Any) = conj(x) 및 conj(x::Any) = x 와 같은 일반적인 무 작업 폴백을 통해 "수학적 adjoint"/ "수학적 전치"와 결합되었습니다. 이러한 대체로 인해 [c]transpose 및 관련 접미사 연산자 ' / .' 가 대부분의 경우 "구조적 전치"에 사용됩니다. 큰. 그러나 그들은 또한 일부 사용자 정의 숫자 유형에 대한 [c]transpose 관련 작업이 해당 유형에 대한 [c]transpose 전문화 정의없이 자동으로 실패 (잘못된 결과 반환)하도록했습니다. 아야. 따라서 이러한 일반적인 no-op 폴 백이 제거되어 현재 상황이 발생했습니다.

문제는 지금 무엇을해야 하는가입니다.

이상적인 결과 : "구조적 전치"를 위해 통합되고 자연스럽고 간결한 주문을 제공합니다. 의미 론적으로 올바른 수학적 adjoint 및 transpose를 동시에 지원합니다. 사용 또는 구현시 까다로운 코너 케이스를 도입하지 마십시오.

두 가지 광범위한 제안이 있습니다.

(1) 수학적 인접, 수학적 전치 및 구조 전치를 구문 적으로, 의미 적으로 구별되는 세 가지 연산으로 제공합니다. 장점 : 모든 것이 작동하도록하고 개념을 명확하게 분리하며 까다로운 코너 케이스를 피합니다. 단점 : 설명하고 구현해야하는 세 가지 작업.

(2) 구둣 주걱은 세 가지 작업을 두 개로 나눕니다. 이 제안에는 세 가지 형태가 있습니다.

(2a) transpose 의미 적으로 "구조적 전치"로 만들고 일반적인 경우 "수학적 전치"로도 사용합니다. 장점 : 두 가지 작업. 스칼라 요소가 모호하지 않은 컨테이너에 대해 예상대로 작동합니다. 단점 : "수학적 전치"의미론을 기대하는 사람은 분명한 스칼라 요소가있는 컨테이너보다 더 복잡한 객체에 대해 잘못된 결과를 자동으로 수신합니다. 사용자가이 문제를 포착하면 "수학적 전치"의미 체계를 달성하려면 새로운 유형 및 / 또는 메서드를 정의해야합니다.

(2b) 유형의 "수학 성"을 나타내는 특성을 소개합니다. 객체에 adjoint / transpose를 적용 할 때 컨테이너 / 요소 유형이 "mathy"이면 반복됩니다. 그렇지 않다면 재귀하지 마십시오. 장점 : 두 가지 작업. 다양한 일반적인 경우를 다룰 수 있습니다. 단점 : 일반적인 no-op [c]transpose 폴 백과 동일한 문제가 있습니다. 즉, 필요한 특성 정의가없는 사용자 정의 숫자 유형에 대해 자동으로 잘못된 결과를 생성 할 수 있습니다. 구조 전치를 "수학"유형으로 적용하거나 수학적 전치를 "수학이 아닌"유형으로 적용 할 수 없습니다. 모든 경우에 객체가 "수학"인지 여부를 결정하는 방법이 명확하지 않습니다. (예 : 요소 유형이 추상이면 어떻게됩니까? 재귀 / 비 재귀 결정은 런타임 및 요소 별 또는 런타임이며 집합 유형을 확인하기 위해 컨테이너의 모든 요소를 ​​먼저 스윕해야합니까?)

(2c) adjoint ( ctranspose ) "mathematical adjoint"및 transpose "mathematical transpose"를 유지하고 adjoint 대한 특수 (일반 대체 아님) 메서드를 도입합니다. / 숫자가 아닌 스칼라 유형의 경우 transpose (예 : adjoint(s::AbstractString) = s ). 장점 : 두 가지 작업. 수학적 의미를 수정합니다. 단점 : 숫자가 아닌 유형에 대해 adjoint / transpose 단편적인 정의가 필요하므로 일반 프로그래밍을 방해합니다. 구조 전치를 "수학"유형에 적용 할 수 없습니다.

제안 (1) 및 (2a)는 (2b) 및 (2c)보다 훨씬 더 광범위한 지원을 받았습니다.

# 19344, # 21037, # 13171 및 slack / # linalg에서 더 많은 토론을 찾으십시오. 베스트!

멋진 글을 써 주셔서 감사합니다!

옵션 1과 잘 어울리는 또 다른 가능성을 표에 추가하고 싶습니다. 수학적 행렬과 표 형식 데이터에 대해 서로 다른 컨테이너 유형을 갖습니다. 다음의 의미 A' 유형에 의해 결정 될 수 A (참고 : 상술 한 바와 같이,하지의 요소 유형). 여기서 단점은 둘 사이에 많은 convert s가 필요할 수 있으며 물론 매우 파괴적 일 수 있다는 것입니다. 물론 혜택이 이러한 중단을 정당화 할 수 있을지 회의적이지만 여전히 언급하고 싶었습니다.

감사합니다, 훌륭한 글입니다. 나는 (1)에 투표합니다.

좋은 글을 쓰세요. (1)의 철자는 다음과 같을 수 있습니다.

• 인접 : a' (재귀, 지연)
• 수학 전치 : conj(a') (재귀, 게으른)
• 구조적 전치 : a.' (비재 귀적, 열망)

따라서 반드시 새로운 연산자를 도입 할 필요는 없습니다. 수학적 전치는 단지 인접 및 켤레의 구성 (게으르고 따라서 효율적인) 일뿐입니다. 가장 큰 문제는 두 개의 유사하게 보이는 연산자, 즉 후위 ' 및 .' 를 의미 상 상당히 구별된다는 것입니다. 그러나 가장 정확한 일반 코드에서 누군가가 ' 또는 .' 을 (를) 사용했는지 여부는 "이것의 인접 항목을 줘"또는 "스왑"을 의미하는지에 대한 99 % 정확한 지표라고 가정합니다. 이 물건의 차원 ". 게다가 누군가가 ' 했고 실제로 "이것의 차원을 바꾸는 것"을 의미하는 경우, 그들의 코드는 스칼라 인접 요소가 사소하지 않은 행렬 (예 : 복소수)에 대해 이미 잘못된 것입니다. 누군가가 실제로 "이것의 결합의 켤레를 줘"를 의미하는 나머지 몇 가지 경우에서, 나는 conj(a') 를 쓰는 것이 실제로 사람들이 실제로 a.' 를 사용하기 때문에 그 의미를 훨씬 더 명확하게 만든다고 주장합니다. " a 의 크기 바꾸기"를 의미합니다.

이를 위해 필요한 모든 기본 제네릭 유형을 작업하는 것은 아직 결정되지 않았지만 @andyferris 와 @andreasnoack은 이미 문제에 대해 몇 가지 생각을 가지고 있으며 가능해 보입니다.

이 토론은 다른 곳에서 진행되었으므로 나도 업데이트해야한다고 생각했습니다. 이 제안에 대해 내가 완전히 놓친 한 가지 (분명한?)가 있다는 것을 인정합니다. 선형 대수에 .' 를 계속 사용할 것이라고 가정했지만 이것이 사실이 아님을 깨달았어야했습니다 !

예를 들어, vector.' 는 더 이상 RowVector 필요가 없습니다 ( RowVector 는 선형 대수 개념이므로 "이중"벡터에 대한 첫 번째 시도)-간단하게 Matrix 이어야합니다. 선형 대수에서 "비공 액 전치"를 원할 때 제가 실제로 하는 것은 conj(adjoint(a)) 입니다. 이것이 우리가 사용하고 모든 선형 대수 사용자가 사용하도록 권장하는 것입니다 (지금까지 내가 정말로 원하는 것이 adjoint 였을 때 내가 알고있는 모든 행렬 (또는 벡터)을 전치하는 데 a' 대신 a.' 사용하는 MATLAB 이후로 오랫동안 "나쁜"습관이있었습니다. adjoint (또는 이중)-이름 변경은 여기서 큰 도움이 될 것입니다).

나는 또한 이것이 흥미로운 공간을 열어 준다는 점을 간단히 지적 할 것이다. 이전에는 vector' 및 vector.' 가 "데이터 전치"를 수행하고 이중 벡터와 같은 것을 취하는 이중 요구 사항을 충족해야했습니다. .' 는 배열 크기를 조작하기위한 것이고 ' 는 선형 대수 개념이므로 RowVector 을 1D DualVector 또는 다른 것으로 변경할 수 있습니다. 전적으로. (아마 여기서 논의하지 말아야 할 것입니다. 누구든지 이에 대한 식욕이 있다면 별도의 문제를 만들어 보겠습니다.)

마지막으로 Slack에서 제안 된 실행 계획을 복사합니다.

1) transpose 을 LinAlg 에서 Base 옮기고 더 이상 RowVector 만들지 않거나 재귀 적이 지 않는다는 depwarns (0.7 만 해당)를 추가합니다 (가능한 경우).
2) ctranspose 을 adjoint
3) Vector , ConjVector 및 RowVector 가 ' 및 conj 및 * 조합에서 작동하는지 확인하십시오 ' RowVector 이름을 바꿉니다. (여기서 우리는 또한 conj(vector) 게으르게 만듭니다).
4) conj 및 ConjMatrix 와도 잘 상호 작용하는 lazy matrix adjoint를 도입하십시오.
5) A_mul_Bc 등을 제거합니다. A_mul_B! 을 mul! (또는 *! )로 바꿉니다.
6) 이익

@stevengj 는 다음

@andyferris , 스칼라의 adjoint 및 dual은 완벽하게 잘 정의되어 있으며 ctranspose(x::Number) = conj(x) 가 정확합니다.

기록을 위해 나는 이것에 확실히 동의합니다.

내 느낌은 대부분의 transpose 사용이 "non-mathy"이고 ctranspose (...)의 대부분의 사용은 수학적이라는 것입니다.

그래서 아이디어는 이것을 공식화하는 것입니다 : transpose 의 모든 사용은 "non-mathy"가되고 adjoint 의 유일한 사용은 "mathy"가됩니다.

예를 들어, vector.' 는 더 이상 RowVector 필요가 없습니다 ( RowVector 는 선형 대수 개념이므로 "이중"벡터에 대한 첫 번째 시도). 간단하게 Matrix 이어야합니다.

그러나 우리는 여전히 .' 가 게으 르기를 원합니다. 예를 들어 X .= f.(x, y.') 는 여전히 할당되지 않아야합니다.

여기에 질문이 있습니다. issymmetric(::AbstractMatrix{<:AbstractMatrix}) 어떻게 구현해야합니까? transpose 와 일치하는 비 재귀 검사일까요? 구현을보고 있습니다. 요소가 transpose 할 수 있다고 가정합니다. OTOH issymmetric(::Matrix{String}) ...

Symmetric btw로 래핑 된 경우 현재 재귀 적이 지 않습니다.

julia> A = [rand(2, 2) for i in 1:2, j in 1:2]; A[1, 2] = A[2, 1]; As = Symmetric(A);

julia> issymmetric(A)
false

julia> issymmetric(As)
true

julia> A == As
true

네, 저는 이것에 대한 PR을 만드는 중이고 이러한 종류의 불일치가 많이 있습니다. (나는 얼마 전에 배열 코드에서 transpose , adjoint 및 conj 모든 인스턴스를 검색하는 동안 발견했습니다).

달리 지시하지 않는 한 issymmetric(a) == (a == a.') 및 ishermitian(a) == (a == a') 와 같은 동작을 구현합니다. 이것들은 그 자체로 매우 직관적 인 것처럼 보이며 AFAICT의 기존 issymmetric 은 Number 요소 유형에 대한 것입니다 (또는 중첩 된 배열에 대해 그다지 의미가없는 다른 실수 / 가정이 자주 있습니다) .

(대체 구현은 issymmetric(a) == (a == conj(adjoint(a))) ... "예쁘다"거나 "데이터"배열 ( String 등)에 대해 작동하지 않지만 Number 배열과 일치합니다.

달리 지시하지 않는 한 issymmetric(a) == (a == a.') 및 ishermitian(a) == (a == a') 와 같은 동작을 구현합니다.

나에게 올바른 솔루션 인 것 같습니다.

업데이트 : 내 마음이 바뀌 었습니다. 대칭은 아마도 주로 선형 대수를위한 것입니다.

작은 제안 : 두 벡터의 곱 ( dotu )에 대한 합계를 계산하는 것이 종종 유용하며, 스칼라를 반환하는 x.’y 는이를 수행하는 편리한 방법입니다. 따라서 Matrix 에서 transpose(::Vector) Matrix 를 반환하지 않는 것이 좋습니다.

예, RowVector 이므로 스칼라를 가져와야합니다. (조옮김은 재귀 적이 지 않습니다).

접선적인 코멘트에 대해 미안하지만이 스레드의 많은 사람들이 "벡터 공간의 스칼라 링"에 대해 계속 이야기합니다. 정의에 따라 벡터 공간의 스칼라는 링뿐만 아니라 필드를 형성해야합니다. 벡터 공간과 매우 유사하지만 스칼라가 필드가 아닌 링만 형성하는 대수 구조를 "모듈"이라고합니다.하지만 모듈은베이스에서 처리하기에는 너무 난해하다고 생각합니다. .. 모듈.

정수 배열을 지원하므로 벡터 공간뿐만 아니라 모듈도 효과적으로 지원합니다. 물론 정수 배열을 부동 소수점 배열에 포함 된 것으로 동작 적으로 볼 수도 있으므로 벡터 공간의 부분 표현입니다. 그러나 우리는 모듈 형 정수 배열을 만들 수도 있습니다 (예를 들어). 비 프라임 모듈러스를 사용하면 어떤 필드에도 자연스럽게 포함되지 않는 링으로 작업 할 것입니다. 간단히 말해서, 우리는 실제로 단순한 벡터 공간보다는 일반적으로 모듈을 고려하고 싶지만, 우리의 목적에 큰 차이는 없다고 생각합니다 (일반적으로 + 와 * 대해서만 이야기합니다).

예, Julia는 실제 벡터 공간뿐만 아니라 일반 모듈에서 대수 연산을 확실히 지원합니다. 하지만 내가 이해하는 바와 같이 커뮤니티의 일반적인 철학은 Base 함수는 " '일반적인'일반 선형 대수 루틴"을 염두에두고 설계되어야한다는 것입니다. 예를 들어 정수 행렬에 대한 정확한 선형 대수 계산은 ' Base 에 속하지 않음 -따라서 기본적인 디자인 결정을 내릴 때 스칼라가 필드를 형성한다고 가정해야합니다. (당신이 말했듯이, 실질적으로 말하자면, 그것은 그다지 중요하지 않습니다.)

크로스 포스팅 https://github.com/JuliaLang/julia/pull/23424#issuecomment -346678279

이 pull 요청이 나타내는 # 5332 및 # 20978을 앞으로 이동하려는 노력에 감사 드리며, 대부분의 관련 계획에 참여하고 있습니다. 나는 또한이 풀 리퀘스트가 발전하는 용어 선택과 다운 스트림 영향에 동참하고 싶고, 그러한 선택이 사용 가능한 최상의 트레이드 오프 세트를 산출한다는 것을 정기적으로 스스로 확신 시키려고 노력합니다.

내가 그 입장을 확신하려고 할 때마다 나는 똑같은 일련의 불안에 좌초한다. 이러한 잘못된 점 중 하나는이 선택이 LinAlg 강요하는 상당한 구현 복잡성입니다. 전치와 배열 뒤집기를 합치면 LinAlg 가 둘 다 처리해야하므로 LinAlg 는 훨씬 더 큰 집합을 지원해야합니다. 일반적인 작업에서 유형 조합.

고려 설명하기 mul(A, B) 여기서 A 및 B 되어 맨손으로, 수반 행렬 싸서, 전치 감싸거나 배열 플립 래핑 Matrix S. 전치와 배열 뒤집기를 병합하지 않고 A 는 Matrix , adjoint-wrapped Matrix , transpose-wrapped Matrix (그리고 마찬가지로 B ). 따라서 mul(A, B) 은 9 가지 유형 조합을 지원해야합니다. 그러나 전치와 배열 뒤집기를 병합하면 A 는 Matrix , adjoint-wrapped Matrix , transpose-wrapped Matrix 또는 array-가 될 수 있습니다. 뒤집어서 포장 된 Matrix (그리고 마찬가지로 B ). 이제 mul(A, B) 은 16 개의 유형 조합을 지원해야합니다.

이 문제는 인수 수에 따라 기하 급수적으로 악화됩니다. 예를 들어, conflation없이 mul!(C, A, B) 는 27 가지 유형의 조합을 지원해야하는 반면, conflation을 사용하면 mul!(C, A, B) 는 64 가지 유형의 전투를 지원해야합니다. 그리고 물론 Vector s 및 비 Matrix 매트릭스 / 연산자 유형을 혼합에 추가하면 상황이 더욱 복잡해집니다.

이 변화를 진행하기 전에이 부작용을 고려할 가치가있는 것 같습니다. 베스트!

이 게시물은 github, slack 및 분류에 대한 최근 논의를 통합 / 검토하고 가능한 경로를 분석합니다. (https://github.com/JuliaLang/julia/issues/20978#issuecomment-315902532의 영적 후계자는 1.0에 도달하는 방법에 대한 생각에서 태어났습니다.)

의미 상으로 구별되는 세 가지 작업이 문제가됩니다.

• adjoint (선형 대수, 재귀, 이상적으로는 기본적으로 게으름)
• 전치 (선형 대수, 재귀, 이상적으로는 기본적으로 게으름)
• array-flip (abstract-array-ic, non-recursive, 이상적으로는 기본적으로 "lazy")

마스터에서 이러한 작업의 상태

• Adjoint는 adjoint / ' (하지만 ' 특별히 낮추어 진 표현식을 A[c|t]_(mul|rdiv|ldiv)_B[c|t][!] 호출로 낮추어 중간 열의 adjoint / 전치를 피합니다) .

• 조옮김은 transpose / .' ( adjoint 와 동일한주의 사항).

• 배열 플립라고 permutedims(C, (2, 1)) 대한 이차원 C 및 reshape(C, 1, length(C)) 일차원 대한 C .

관련 문제

1. 5332 : A[c|t]_(mul|rdiv|ldiv)_B[c|t] 로의 특별 하강 및 관련 메서드 이름 조합 모음이 1.0만큼 사라져야합니다. 특별한 낮추기 / 관련 메서드 이름을 제거하려면 lazy adjoint 및 transpose가 필요합니다.

2. 13171 : Adjoint (née ctranspose ) 및 조옮김은 이전에 transpose(x::Any) = x , ctranspose(x::Any) = conj(x) 및 conj(x::Any) = x 와 같은 일반적인 no-op 폴백을 통해 배열 뒤집기와 결합되었습니다. 이러한 폴백으로 인해 일부 사용자 정의 숫자 유형에 대한 [c]transpose 관련 작업은 해당 유형에 대한 [c]transpose 전문화없이 자동으로 실패 (잘못된 결과 반환)됩니다. 잘못된 결과를 자동으로 반환하는 것은 나쁜 소식이므로 이러한 대체가 제거되었습니다 (# 17075). 더 조용한 실패를 도입하지 않는 것이 좋습니다.

3. 17075, # 17374, # 19205 : 이전 폴백을 제거하면 어레이 플립이 덜 편리해졌습니다. 그리고 (사과, 내 잘못) 그다지 크지 않은 관련 지원 중단 경고와 함께 제거 (일시적으로?)가 불만을 제기했습니다. 배열 뒤집기에 대한 더 편리한 주문이 좋을 것입니다.

4. 21037 : 1.0에 대해 지금 혼란스러운 .' 구문을 제거하는 것은 멋질 것입니다. 이 변경을 가능하게하려면 위에서 언급 한 특별 하강을 제거해야합니다.

이러한 문제를 해결하기위한 설계 목표

특수 하강 및 관련 메서드 이름을 제거하고, 자동 실패를 방지하고, 전치 및 배열 반전을위한 직관적이고 편리한 주문을 제공하고 .' 제거합니다. 최소한의 추가 복잡성과 파손으로 선행을 달성하십시오.

디자인 제안

이 분야는 두 가지 디자인 제안으로 축소되었습니다.

1. adjoint adjoint , transpose conjadjoint ( "conjugate adjoint") 및 array-flip transpose 호출합니다. adjoint 및 conjadjoint 는 LinAlg 거주하고 transpose 는 Base 거주합니다.

2. adjoint adjoint , transpose transpose 및 array-flip flip 호출합니다. adjoint 및 transpose 는 LinAlg 거주하고 flip 는 Base 거주합니다.

처음에는 이러한 제안이 표면적으로 만 달라 보입니다. 그러나 더 자세히 살펴보면 실질적인 차이가 큽니다. 이러한 명명 체계의 상대적인 피상적 인 장점에 대한 논의를 피하면서 실질적인 차이점을 살펴 보겠습니다.

차이점, 높은 수준의보기

1. 복잡성:

   제안 1은 array-flip transpose 를 호출하여 LinAlg 를 강제로 전치 및 adjoint 외에도 array-flip을 처리합니다. 따라서 LinAlg 는 일반적인 작업에서 지원하는 형식 조합 집합을 크게 확장해야합니다. https://github.com/JuliaLang/julia/pull/23424#issuecomment -346678279는 이러한 추가 복잡성을 예시로 보여 주며, 다음 논의는 추가 복잡성이 존재 함을 암시 적으로 확인합니다.

   제안 2에는 LinAlg 지원 만 전치 및 adjoint가 필요합니다. LinAlg 에서는 지금 지원합니다.

2. 파손:

   제안 1은 기존 작업의 기본 의미를 변경합니다. transpose 는 전치가 아닌 배열 뒤집기가되고 모든 transpose 관련 기능은 그에 따라 변경되어야합니다. (예를 들어 transpose 라는 이름과 관련된 LinAlg 모든 곱셈 및 왼쪽 / 오른쪽 나누기 작업에는 의미 수정이 필요합니다.)이 변경이 실현되는 방식에 따라이 변경으로 인해 자동 손상이 발생합니다. 현재 의미론이 (의도적으로 또는 우연히) 의존하는 모든 곳.

   제안 2는 모든 기존 작업의 기본 의미를 유지합니다.

3. 커플 링:

   제안 1은 선형 대수 개념 (전치)을 Base , 추상 배열 개념 (배열 뒤집기)을 LinAlg 로 가져와 Base 및 LinAlg 강력하게 결합합니다.

   제안 2는 추상 배열과 선형 대수를 명확하게 분리하여 전자는 기본에만 있고 후자는 새로운 결합없이 LinAlg 에서만 살 수 있습니다.

4. 무음 vs. 큰 실패 :

   제안 1은 transpose 호출하여 전치 의미론을 기대할 때 조용히 잘못된 결과를 초래합니다 (대신 배열 뒤집기 의미론을 얻음).

   제안 2의 아날로그는 배열 뒤집기 의미론을 기대하는 숫자가 아닌 배열에서 transpose 를 호출합니다. 이 경우 transpose 는 사용자에게 flip 를 가리키는 오류를 발생시킬 수 있습니다.

5. .' : .' 지원하지 않는 기본 인수는 transpose 의 길이입니다. 제안 1은 .' 를 transpose 및 conjadjoint 이름으로 대체하지만 상황을 개선하지는 않습니다. 반대로 제안 2는 flip 및 transpose 이름을 제공하여 상황을 개선합니다.

1.0 경로의 차이점

1.0을 얻는 것은 각 제안에서 무엇을 취합니까? 제안 2에서는 1.0으로의 경로가 더 간단하므로 여기서 시작하겠습니다.

제안 2에 따른 1.0으로가는 길

1. lazy adjoint를 도입하고 LinAlg 에 래퍼 유형을 전치합니다 (예 Adjoint 및 Transpose . mul[!] / ldiv[!] / rdiv[!] 메서드를 해당 래퍼 유형에 디스패치하고 해당 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 메서드의 코드를 포함하는 방법을 소개합니다. 후자의 방법을 이전 방법의 짧은 자식으로 다시 구현합니다.

   이 단계는 아무것도 중단하지 않으며 즉시 .' 의 특별 하강 및 지원 중단을 제거 할 수 있습니다.

2. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 를 산출하는 특수 하강을 제거하십시오. 대신 ' / .' 를 Adjoint / Transpose 낮추십시오. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 호출을 생성하는 이전에 특별히 낮은 표현식은 대신 mul / ldiv / rdiv 호출이됩니다. 해당 mul[!] / ldiv[!] / rdiv[!] 메서드에 대한 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 을 중단합니다. .' 사용하지 않습니다.

   이 단계는 0.7에서 수행 할 수 있습니다. (1) Base / LinAlg 유형이 아닌 경우 Base A[c|t]_{mul|ldiv|rdiv}_B[c|t] 메서드를 적중하기 위해 특수 하강에 의존하는 코드는 중단됩니다. 이러한 코드는 새로운 저하 수율 / 깨진 코드가 마이그레이션해야하는 대상을 나타내는 명시적인 MethodError 를 방출합니다. (2) 고립 된 ' s / .' s에 의존하는 코드는 엄격하게 열성적으로 작동합니다. 일반적인 실패 모드는 명시 적 MethodError 여야합니다. 모든 곳에서 파손은 제한적이고 시끄 럽습니다.

   이것이 1.0에 꼭 필요한 변경 사항입니다.

   이 시점에서 Adjoint(A) / Transpose(A) 는 lazy adjoint 및 transpose를 생성하고 adjoint(A) / transpose(A) 는 eager adjoint 및 transpose를 생성합니다. 후자의 이름은 무기한으로 유지되거나, 원하는 경우 0.7의 다른 철자로 더 이상 사용되지 않을 수 있습니다 (예 eagereval(Adjoint(A)) / eagereval(Transpose(A)) 모듈로 철자 eagereval 또는 eageradjoint(A) / eagertranspose(A) 지원 중단의 경우 adjoint / transpose 은 (는) 1.0에서 용도 변경 될 수 있습니다 ( Adjoint(A) / Transpose(A) 정도는 사용하지만 필요한).

   드디어...

3. 도입 flip 및 / 또는 Flip 에서 Base . 기능 추가이므로 필요한 경우 1.x에서 이러한 변경이 발생할 수 있습니다.

제안 1에 따른 1.0으로의 경로

제안 1은 어떻습니까? 아래에는 가능한 두 가지 경로가 나와 있습니다. 첫 번째 경로는 0.7의 변경 사항을 통합하지만 조용한 파손을 포함합니다. 두 번째 경로는 조용한 파손을 피하지만 0.7-> 1.0의 더 많은 변경을 포함합니다. 두 개요 모두 ​​코드베이스를 지속적으로 발전시킵니다. 덜 연속적인 등가물은 일부 작업 / 이탈을 통합 / 회피 할 수 있지만 더 어렵고 오류가 발생하기 쉽습니다. 진행중인 작업은 겉보기에 첫 번째 경로를 따릅니다.

제안 1의 첫 번째 경로 (침묵 한 파손 포함)

1. transpose 의 의미 체계를 전치에서 배열 뒤집기로 변경하고 반드시 모든 transpose 관련 기능의 의미 체계도 변경합니다. 예를 들어 At_... 하거나 ..._Bt[!] 끝나는 모든 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 메서드에는 잠재적으로 의미 수정이 필요합니다. 또한 예를 들어 Symmetric / issymmetric 의 정의 및 동작을 변경해야합니다. transpose 자체를 Base 합니다.

   이러한 변화는 조용하고 광범위하게 깨질 것입니다.

2. conjadjoint 에 LinAlg 합니다. 이 단계에서는 이전 단계에서 건드린 모든 메서드를 원래 의미 형식으로 복원해야하며 이제 conjadjoint 와 연결된 다른 이름 (예 Aca_... 및 ..._Bca[!] 이름)을 사용합니다. . 또한 배열 뒤집기 (현재 transpose ), 전치 (현재 conjadjoint ) 및 LinAlg adjoint를 동시에 지원하는 추가 유형 조합에 대한 메서드를 추가해야합니다 (예 : ca 들 사이에서 변형 A[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!] ).

3. LinAlg lazy adjoint 및 전치 ( conjadjoint 라고 함)를 도입하고 Adjoint 및 ConjAdjoint 라고 말합니다. (라는 게으른 배열 플립 소개 transpose 의 타입 래퍼) Base 말, Transpose . mul[!] / ldiv[!] / rdiv[!] 메서드를 해당 래퍼 유형에 디스패치하고 해당 A[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!] 메서드의 코드를 포함하는 방법을 소개합니다. 후자의 방법을 이전 방법의 짧은 자식으로 다시 구현합니다.

4. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 를 산출하는 특별 하강을 제거하십시오. 대신 ' / .' 를 Adjoint / Transpose 낮추십시오. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 호출을 생성하는 이전에 특별히 낮은 표현식은 대신 mul / ldiv / rdiv 호출이됩니다 (시맨틱이 조용히 변경 될 것임을 상기하십시오). 해당 mul[!] / ldiv[!] / rdiv[!] 메서드에 대한 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 을 중단합니다. 마찬가지로 최근에 도입 된 Aca_... / ...Bca[!] 메서드를 제거하여 mul[!] / ldiv[!] / rdiv[!] 등가물을 사용합니다. .' 사용하지 않습니다.

이러한 변경 사항은 0.7에서 진행되어야합니다. 기존 작업에 대한 의미 변경은 광범위하고 조용한 파손을 초래합니다. 특수 하강 제거는 위에서 설명한 것과 동일한 제한적이고 큰 파손을 생성합니다.

이 시점에서 Adjoint(A) / Transpose(A) / ConjAdjoint(A) 는 각각 lazy adjoint, array-flip 및 transpose를 생성하고 adjoint(A) / transpose(A) / conjadjoint(A) 는 각각 eager adjoint, array-flip 및 transpose를 생성합니다. 후자의 이름은 무기한으로 유지되거나 원하는 경우 0.7에서 다른 철자에 더 이상 사용되지 않을 수 있습니다 (위 참조).

이 프로세스의 초기에 ConjAdjoint 도입하여 일부 작업 / 이탈을 통합 / 방지 할 수 있지만, 이러한 접근 방식은 더 어렵고 오류가 발생하기 쉽습니다.

제안 1에 따른 두 번째 경로 (침묵 한 파손 방지)

1. 열망 소개 conjadjoint 에서 LinAlg . 현재 transpose 와 관련된 모든 기능 및 메서드 (예 : A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 관련 t A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 메서드 포함)를 conjadjoint 및 파생 이름으로 마이그레이션합니다. 모든 transpose 관련 이름을 새로운 conjadjoint 등가물의 짧은 하위로 만듭니다. 모든 transpose 관련 이름을 conjadjoint 해당하는 이름으로 사용하지 않습니다.

2. (라고 게으른 수반 행렬과 전치 소개 conjadjoint 의 타입 래퍼) LinAlg 말할 Adjoint 및 ConjAdjoint . mul[!] / ldiv[!] / rdiv[!] 메서드를 해당 래퍼 유형에 디스패치하고 해당 A[c|ca]_{mul|ldiv|rdiv}_B[c|ca][!] 메서드의 코드를 포함하는 방법을 소개합니다. 후자의 방법을 이전 방법의 짧은 자식으로 다시 구현합니다.

3. Base 에 Transpose 라는 lazy array-flip 래퍼 유형을 도입합니다 (약간 혼란스럽게도, 동시에 transpose 는 전치 의미를 사용하여 conjadjoint 로 사용되지 않음). 배열 뒤집기 ( Transpose )에 필요한 모든 일반 메서드를 Base 합니다. 그런 다음 배열 뒤집기를 동시에 지원하는 모든 추가 유형 조합에 대해 LinAlg 에 메서드를 추가합니다 (현재 Transpose ,하지만 transpose 아님), 전치 (현재 conjadjoint 및 ConjAdjoint ), LinAlg adjoint는 필요합니다 (예 : mul[!] / rdiv[!] / ldiv[!] A[c|t|ca]_{mul|ldiv|rdiv}_B[c|t|ca][!] 현재 존재하지 않음).

4. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 를 산출하는 특별 하강을 제거하십시오. 대신 ' / .' 를 Adjoint / Transpose 낮추십시오. A[c|t]_{mul|ldiv|rdiv}_B[c|t] 호출을 생성하는 이전에 특별히 낮은 표현식은 대신 mul / ldiv / rdiv 호출이됩니다. 해당 mul[!] / ldiv[!] / rdiv[!] 메서드에 대한 A[c|t]_{mul|ldiv|rdiv}_B[c|t][!] 을 중단합니다. .' 중단.

앞의 변경 사항은 0.7로 이동해야합니다. 조용한 파손이없고, 위에서 설명한대로 특수 하강 제거에서 큰 파손 만 발생합니다.

이 시점에서 Adjoint(A) / Transpose(A) / ConjAdjoint(A) 는 각각 lazy adjoint, array-flip 및 transpose를 생성합니다. adjoint(A) / conjadjoint(A) 는 각각 eager adjoint 및 transpose를 생성합니다. transpose(A) 는 conjadjoint 더 이상 사용되지 않습니다. transpose 는 원하는 경우 1.0에서 용도를 변경할 수 있습니다. adjoint 는 무기한으로 유지되거나 0.7의 다른 철자를 위해 더 이상 사용되지 않을 수 있습니다. conjadjoint 철자를 쓰는 또 다른 방법은 0.7로 직접 들어갈 수 있습니다.

1 단계와 2 단계를 다소 통합하여 작업 / 이탈을 피할 수 있지만, 이러한 접근 방식은 더 어렵고 오류가 발생하기 쉽습니다.

#

읽어 주셔서 감사합니다!

훌륭한 글에 감사드립니다. 나는 일반적으로 제안 2에 동의합니다. 추가적인 이유는 conjugate adjoint가 전혀 표준 용어가 아니며 개인적으로 매우 혼란 스럽습니다. 활용이 일어난다는 것을 암시하는 것 같습니다).

나는 위의 정교한 토론을 읽으려고했지만 어떤 시점에서 수학적인 transpose 가 재귀 적이어야한다고 결정 / 동기화되었는지 확인하지 못했습니다. 이것은 (7 월 14 일에서 18 일 사이에) 사적인 토론에서 뒤따른 것처럼 보였고, 그 후 갑자기 수학적 구조적 전치가 도입되었습니다.
@ Sacha0 는 그것을 다음과 같이 설명합니다.

발생 방법 : 이전에 "구조적 전치"는 "수학적 adjoint"/ "수학적 전치"와 결합되었습니다.

나는 (구조적) 전치가 "adjoint"와 합쳐 졌는데 동의하지만 여기서 "수학적 전치"가 갑자기 나타납니다. 완전성 / 자립성을 위해 그 개념과 그것이 재귀 적이어야하는 이유를 간략하게 반복 / 요약 할 수 있습니까?

그와 관련하여, 나는 행렬의 전치가 작동하지 않는 객체가 될 것이라는 단순한 이유 때문에 추상적 인 수학적 의미에서 transpose 를 선형 맵 에 대한 RowVector 에서는 RowVector 를 RowVector 매핑합니다. 재귀 전치에 대한 주장이 부족한 점을 감안할 때 일반적으로 (기초 종속) 개념으로 정의되는 일반 행렬 전치와 새로 제안 된 flip 연산 사이에 차이가 없습니다.

훌륭한 글을 작성해 주신 @ Sacha0 에게 감사드립니다. 제안 2를 선호합니다 (adjoint adjoint 호출, transpose 전치 및 array-flip flip . adjoint 및 transpose 는 LinAlg 거주 flip 는 Base 거주합니다.). 나에게 이것은 최상의 최종 결과 (주요 관심사가되어야 함)를 제공하는 것으로 보이며 v1.0에 대한 더 깨끗한 방법을 허용합니다. 위의 요점에 동의하므로 반복하지 않겠습니다. 여기에 몇 가지 추가 설명이 있습니다.

비재 귀적 transpose 에 찬성하는 한 가지 주장은 .' -구문이 매우 편리하므로 예를 들어 Matrix{String} 입니다. 이 구문을 가정하면 (# 21037)를 멀리가는 사람이 사용할 필요가있다 transpose(A) 대신 A.' , 그때는 생각 flip α- 함수가 (짧은 환영 보탬이 될 것입니다 transpose(A) 보다 명확하고 permutedims(A, (2,1)) 보다 확실히 좋습니다).

제안 2가 제공하는 LinAlg 와 Base 사이의 분리도 매우 좋습니다. LinAlg 는 Transpose 및 Adjoint 를 처리하는 방법 만 신경 쓸 필요가있을뿐만 아니라 transpose 및 adjoint 고려한다는 점을 분명히합니다 LinAlg 연산이되고 flip 는 행렬의 차원을 뒤집는 일반 AbstractMatrix 항목이됩니다.

마지막으로 transpose(::Matrix{String}) 등이 작동하지 않는다는 불만을 많이 보지 못했습니다. 정말 일반적인 사용 사례입니까? 대부분의 경우 어쨌든 처음부터 뒤집힌 행렬을 구성하는 것이 좋습니다.

이 명명 체계 (제안 2)가 실제로 더 좋을 수 있습니다. Adjoint 및 Transpose는 선형 대수학에서 꽤 표준 용어이며 덜 깨지는 것입니다.

그러나 수학적 전치가 재귀 적이어야한다고 결정 / 동기화 된 시점을 보지 못했습니다.

@Jutho 그것은 adjoint와 같은 인수입니다 (복소수의 adjoint는 conjugate입니다 (복소수는 유효한 랭크 1 벡터 공간 및 선형 연산자이므로 내적 및 adjoint 개념이 적용됨). 블록 행렬의 adjoint 재귀 적입니다 ...). 예를 들어 사람들은 중첩 된 실수 행렬로 선형 대수를 원할 수 있습니다. "실제 행렬 또는 벡터의 인접"에 대해 .' 를 사용하는 많은 코드를 볼 수 있으며이 작업도 수행했습니다. 여기에서 ' 는 유효 할뿐만 아니라 더 일반적입니다 (복잡한 값 및 / 또는 중첩 될 수있는 배열에서 작동). 중첩 된 복합 행렬에 대한 재귀 전치의보다 진정한 사용은 방정식이 conj(adjoint(a)) 줄 때 발생합니다. 이는 상대적으로 드물지만 여전히 발생합니다 (관련된 함수가없는 경우 만족할만큼 드물게 발생합니다. 위의 토론과 다른 곳에서 다양한 사람들이 "수학적 전치"와 같은 다른 이름으로 부르기 시작했습니다. 저는 conjadoint 를 선택했지만 transpose 자체를 제외하고는 훌륭한 용어 IMO가 아닙니다). 선형 대수학에서 블록 행렬의 블록을 재 배열하지만 블록 자체에 아무것도하지 않는 비 재귀 연산은 일반적으로 나타나지 않습니다.

마지막으로 transpose(::Matrix{String}) 등이 작동하지 않는다는 불만을 많이 보지 못했습니다. 정말 일반적인 사용 사례입니까? 대부분의 경우 어쨌든 처음부터 뒤집힌 행렬을 구성하는 것이 좋습니다.

줄리아의 방송 운영에서는 이런 것이 상당히 바람직하다고 생각합니다. 예를 들어, 일부 데이터의 외부 (Cartesian) 곱을 가져 와서 함수를 통해 매핑하는 것은 매우 일반적입니다. 따라서 map(f, product(a, b)) 대신 broadcast(f, a, transpose(b)) 또는 간단히 f.(a, b.') 있습니다. 소수의 캐릭터로 많은 힘을 발휘합니다.

내 생각 :이 공간 (예 : flip )에 더 많은 함수 이름을 추가하지 않으려면 permutedims(a) = permutedims(a, (2,1)) 의 순열에 대한 기본값을 가질 수 있는지 궁금합니다. 불행히도 이것은 flip 만큼 짧지는 않지만 전체 permutedims(a, (2,1)) 형식보다 훨씬 덜 불쾌합니다 (사용자에게보다 일반적인 기능에 대해 교육하는 부작용이 있습니다).

( @ Sacha0 여기에 글을 Adjoint 와 Transpose 래퍼 중에서 선택하거나 RowVector + MappedArray 이전에 계획된 행렬 (아마도 PermutedDimsArray ), 나는 여전히 후자를 선호하는 경향이 있습니다 ...)

중첩 된 복소 행렬에 대한 재귀 전치의보다 진정한 사용은 방정식이 conj(adjoint(a)) 제공 할 때 발생합니다.

방정식에서 conj(adjoint(a)) 를 얻으면 실제로 conj 이 행렬 항목에 적용하고 싶고 adjoint 아니라는 것을 어떻게 알 수 있습니까? adjoint.(adjoint(a))

이것은 아마도 저를 금지 / 추방 당할 것입니다. 그러나 저는 전체 재귀 적 아이디어의 열렬한 팬은 아닙니다. 나는 반드시 그것에 반대하지는 않습니다. 벡터와 연산자 / 행렬이 재귀 적으로 정의되지 않았기 때문에 수학적으로 엄격한 이유가 있다고 생각하지 않습니다. 스칼라 필드에 대해 정의됩니다 (원하는 경우 확장 링에 의해 정의 됨). 벡터 공간 대신 ​​모듈로도 작업). 따라서 Base.LinAlg는이 경우에만 작동합니다. 주요 주장

벡터의 adjoint는 벡터를 스칼라에 매핑하는 선형 연산자 여야합니다. 즉, a가 벡터 인 경우 a '* a는 스칼라 여야합니다.

Julia Base의 작동 방식과 호환되지 않습니다. a=[rand(2,2),rand(2,2)] 만들고 a'*a 관찰하십시오. 스칼라가 아닙니다. 그렇다면 a 는 행렬로 채워진 벡터이기 때문에 이제 행렬입니까? 위는 실제로 2x2 행렬의 링을 모듈을 정의한 스칼라로 사용하려는 경우에만 스칼라입니다. 그러나 그러한 맥락에서 위의 결과가 의도 한 결과라는 것이 분명하지 않습니다. 유클리드 내부 제품은 어쨌든 모듈 등의 맥락에서 거의 사용되지 않으므로 Base가 올바른 동작을 정의하는 데 신경 쓰지 않아야한다고 생각합니다.

따라서 위의 진술이 행렬로 채워진 행렬을 블록 행렬로 해석하는 것 이상으로 동기를 확장하려는 시도 일 수 있지만 결국에는 블록 행렬 해석이 adjoint 를 만드는 유일한 동기라고 생각합니다. 처음에는 transpose (수학적 의미에서는 사용되지 않지만 항상 플립 매트릭스 인덱스에서는 사용됨)조차도 재귀 적입니다. 새 스칼라 필드 유형을 직접 정의하는 경우 사용하기 전에 adjoint 및 transpose 외에 conj 를 정의해야하는 것은 이상한 부담입니다. 매트릭스에서.

그렇다면 Julia와 같은 강력한 유형 시스템을 사용하여 단순히 블록 행렬 전용 유형을 갖는 것이 아닙니다. 따라서 악마의 옹호자 역할 :

• 실제 작업을 위해 adjoint의 현재 재귀 동작을 실제로 사용 / 의존하는 사람은 몇 명입니까?
• 이러한 재귀 적 접근 방식을 사용하는 다른 언어가 있습니까? (행렬의 셀을 사용하는 Matlab은 그렇지 않습니다)

말했듯이, 나는 특히 transpose 케이스의 경우 (위의 모든 토론을 읽은 후에도) 유효성에 의문을 제기하는 것이 아니라 반드시 반대하는 것은 아닙니다.

이것은 아마도 나를 금지 / 추방 당할 것입니다.

나는 이것이 농담이라는 것을 알고 있지만 인기가없는 의견을 가진 사람은 절대로 금지되지 않습니다. 장기간 계속되는 나쁜 행동 만이 금지로 이어질 수 있습니다. 그럼에도 불구하고 금지는 영구적이지 않습니다 .

벡터와 연산자 / 행렬이 재귀 적으로 정의되지 않았기 때문에 수학적으로 엄격한 이유가 없다고 생각합니다. 스칼라 필드에 대해 정의됩니다 (벡터 공간 대신 ​​모듈로 작업하려는 경우 확장 링으로도 정의 됨). ).

이 진술은 나에게 의미가 없습니다. 벡터로 구성된 벡터, 함수로 구성된 벡터 또는 행렬로 구성된 벡터는 + 및 * scalar 재귀 적으로 정의 된 벡터 공간 (기본 스칼라 필드 위에)을 형성하며 유사하게 형성됩니다. 내적이 재귀 적으로 정의 된 내적 공간. 벡터가 "스칼라의 열"일 수만 있다는 생각은 수학, 물리학 및 공학의 정의와 일반적인 사용을 모두 위반합니다.

a=[rand(2,2),rand(2,2)] 만들고 a'*a 관찰합니다. 스칼라가 아닙니다.

이 경우 a 의 "스칼라 링"은 2x2 행렬의 링입니다. 따라서 이것은 adjoint가 작동하는 방식의 문제가 아니라 언어 문제입니다.

a'*a 이 Julia에서 현재 작동하는 (또는 작동하지 않는) 방식에서 어떻게 작동

새 스칼라 필드 유형을 직접 정의하는 경우 사용하기 전에 adjoint 및 transpose 외에 conj 를 정의해야하는 것은 이상한 부담입니다. 행렬에서

이 부담은 실제보다 심미적이라고 생각합니다. Number 의 하위 유형으로 만들어도 괜찮다면 아무것도 정의 할 필요가 없으며 Number 이 옳지 않다고 생각하더라도 정의가 너무 사소해서 그들을 추가하는 것은 거의 부담이되지 않습니다.

그렇다면 Julia와 같은 강력한 유형 시스템을 사용하여 단순히 블록 행렬 전용 유형을 갖는 것이 아닙니다.

https://github.com/KristofferC/BlockArrays.jl/ 기여자 환영 :)

"금지"농담에 대해 사과드립니다. 이 토론을 더 이상 방해하지 않기위한 마지막 반응이 될 것입니다. 재귀 적 adjoint (아마도 전치가 아님)가 정해 졌음이 분명하며, 그 결정을 취소하지 않으려 고합니다. 나는 단지 몇 가지 불일치를 지적하려고 노력하고 있습니다.

@StefanKarpinski : 스칼라 링의 예는 재귀와 정확히 모순됩니다. 2x2 행렬 자체가 스칼라입니까, 아니면 정의가 재귀적이고 기본 Number 유형이 스칼라입니까?

전자의 경우 실제로 벡터 공간 대신 ​​모듈이 있으며 해당 '스칼라'에 대해 conj 또는 adjoint 를 원하는지 여부에 따라 사용 사례에 따라 달라질 수 있습니다. 내부 제품과 adjoint를 사용합니다.

나는 후자의 정의를 받아 들여도 괜찮습니다. 나는 내 직업에서 슈퍼 벡터 공간의 등급이 매겨진 텐서 곱의 그룹 불변 부분 공간에서 임의의 요소를 사용하고 있으므로 벡터 정의에서 실제로 숫자 열에 국한되지 않습니다. 그러나 행렬의 벡터는 순수한 벡터일까요 아니면 일부 행렬 동작을 상속해야할까요? 전자의 경우 dot(v,w) 는 해당 요소에 대해 vecdot 를 재귀 적으로 호출하여 스칼라를 생성해야합니다. 후자의 경우 적어도 vecdot(v,w) 는 재귀 적으로 작동하여 스칼라를 생성해야합니다. 따라서 재귀 adjoint와 일치하도록 최소한의 수정이 될 것입니다.

그러나 재귀 transpose 를 사용하지 않고 수학이 아닌 응용 프로그램에도 사용할 수 있도록 허용하는 것이 더 간단 해 보입니다. 일반적인 행렬 방정식에서도 실제 수학 전치와는 거의 관련이 없다고 생각하기 때문입니다. 선형지도의.

dot 는 vecdot 아니라 dot 재귀 적으로 호출해야한다고 생각합니다. 따라서 행렬에 대한 표준 내부 곱을 정의하지 않았으므로 행렬 벡터에 오류가 발생합니다.

전치가 재귀 적이라는 사실에 항상 놀랍고 .. 누구도 그렇지 않다는 것을 상상할 수 없습니다. (나는이 논의 때문에“선형지도의 전치”위키피디아 기사에 대한 견해가 적어도 세 배가되었다고 생각합니다.)

저도 종종 재귀 적 정의가 불안정하다는 것을 발견했으며 일반적으로 @Jutho가 표현한 견해를 공유했습니다 (하지만 다시 우리는 매우 유사한 훈련을 받았습니다).

나는 여기서 나를 괴롭히는 불일치를 알아 냈다고 생각합니다. 여기에서는 복소수의 2x2 행렬 임베딩과 같은 링과 필드를 계속 사용하지만 실제로는 재귀 전치 (그리고 인접 ).

설명하겠습니다. 내가 광범위하게 동의하는 것

1. 스칼라는 유효한 순위 1 선형 연산자입니다. Julia의 강력한 유형 시스템을 감안할 때 adjoint 와 같은 LinAlg 개념이 적용되지 않을 이유가 없습니다. 예를 들어 adjoint(z::Complex) = conj(z) 정의해야합니다. (스칼라의 벡터와 행렬 외에도 LinAlg 개념은 다른 객체로 확장 될 수도 있습니다 (사용자에 의해). @stevengj 는 예를 들어 무한 크기의 벡터 공간 (Hilbert 공간)을 언급했습니다).
2. 우리는 표현이 다른 스칼라를 어떻게 든 다룰 수 있어야합니다. 여기의 프로토 타입 예제는 복소수 z = x + y*im 는 Z = x*[1 0; 0 1] + y*[0 1; -1 0] 로 모델링 할 수 있으며 작업 + , - , * , / 및 \ 는이 동형으로 유지됩니다. (그러나 conj(z) 는 adjoint(Z) / transpose(Z) / flip(Z) 합니다.
3. 블록 행렬은 어떻게 든 가능해야합니다 (현재 접근 방식은 기본적으로 재귀 적 adjoint 등에 의존합니다).

Base.LinAlg 이 1과 2와 호환되는 것이 합리적으로 보이지만 IMO 3은 자연스럽게 들어 맞는 경우에만 Base 에서 수행되어야합니다 (그렇지 않으면 https : /와 같은 외부 패키지를 사용하는 경향이 있습니다. /github.com/KristofferC/BlockArrays.jl).

나는 이제 우리가 2와 3을 합친다 는 것을 @Jutho도 이것을 지적했습니다). 아래에서는 3. 재귀 적 adjoint 및 블록 행렬에 따라 다른 연산을 사용하는 것이 2를 제공하지 않는다는 것을 보여주고 싶습니다. 가장 쉬운 방법은 예제입니다. 복소수의 2x2 행렬을 m = [z1 z2; z3 z4] , 동형 표현 M = [Z1 Z2; Z3 Z4] , 표준 2x2 블록 행렬 b = [m1 m2; m3 m4] 로 정의하겠습니다. 여기서 m1 등은 같은 크기의 정사각형입니다. Number 행렬. 일반적인 작업에 대한 의미 상 정답은 다음과 같습니다.

| 운영 | z | Z | m | M | b |
| -| -| -| -| -| -|
| + , - , * | 재귀 | 재귀 | 재귀 | 재귀 | 재귀 |
| conj | conj(z) | Z' 또는 Z.' 또는 flip(Z) | conj.(m) | adjoint.(M) (또는 transpose.(M) ) | conj.(b) |
| adjoint | conj(z) | Z' 또는 Z.' 또는 flip(Z) | flip(conj.(m)) 또는 재귀 | flip(transpose.(m)) 또는 재귀 | 재귀 |
| trace | z | Z | z1 + z4 | Z1 + Z4 | trace(m1) + trace(m4) |
| det | z | Z | z1*z4 - z2*z3 | Z1*Z3 - Z2*Z3 | det(m1) * det(m4 - m2*inv(m1)*m3) ( m1 인버터 블 인 경우, 예 : Wikipedia 참조) |

등의 작업을 고려 trace 및 det 하는 수익 스칼라는, 나는 그것이 우리의 줄리아 형식 시스템 꽤 분명 생각 LinAlg 가능의 내장 우리의 2 × 2 행렬을 처리 할 수 Complex 특정 순간에 "스칼라"가 의미하는 바를 추론하는 "자동"방식으로 trace(Z) 이며 여기서 Z = [1 0; 0 1] 는 2 이고 이것은 1 의 표현입니다. rank(Z) 유사합니다.

일관성을 복구하는 한 가지 방법은 2x2 표현을 스칼라로 명시 적으로 정의하는 것입니다. 예를 들어 아래와 같이 Number 를 하위 타이핑하여 :

struct CNumber{T <: Real} <: Number
    m::Matrix{T}
end
CNumber(x::Real, y::Real) = CNumber([x y; -y x])

+(c1::CNumber, c2::CNumber) = CNumber(c1.m + c2.m)
-(c1::CNumber, c2::CNumber) = CNumber(c1.m - c2.m)
*(c1::CNumber, c2::CNumber) = CNumber(c1.m * c2.m)
/(c1::CNumber, c2::CNumber) = CNumber(c1.m / c2.m)
\(c1::CNumber, c2::CNumber) = CNumber(c1.m \ c2.m)
conj(c::CNumber) = CNumber(transpose(c.m))
zero(c::CNumber{T}) where {T} = CNumber(zero(T), zero(T))
one(c::CNumber{T}) where {T} = CNumber(one(T), one(T))

이러한 정의를 사용하면 일반적인 LinAlg 메서드가 정상적으로 작동 할 것입니다.

결론 : 재귀 적 adjoint 은 블록 행렬과 벡터의 벡터에 편리합니다. 위에서 Z 레이블을 붙인 "스칼라"2x2 행렬 유형에 대한 수학적 정확성에 의해 동기를 부여해서는 안됩니다 . 기본적으로 블록 행렬을 지원할지 여부는 다음과 같은 장단점이 있습니다.

장점

• 블록 어레이 사용자를위한 편의성
• 벡터로 구성된 벡터는 유효한 벡터 공간이고 블록 행렬은 + , * , conj 등에서 유효한 선형 연산자입니다. 이것이 자연스러운 동형으로 만들 수있는 경우 ( CNumber 가 필요한 위의 Z 예제와는 달리), 그렇다면 왜 안됩니까?

단점

• LinAlg 구현에 상당한 추가 복잡성 (잠재적으로 다른 패키지에있을 수 있음).
• eig(block_matrix) 같은 것을 지원하는 것은 약간 어렵지만 불가능하지는 않습니다. LinAlg 가 eig 하고 LinAlg 가 블록 행렬을 지원한다고하면 수정 될 때까지 버그로 간주합니다. LinAlg 제공하는 많은 기능을 감안할 때 우리가 "완료"될 것이라는 것을보기가 어렵습니다.
• transpose 와 같은 작업을 비재 귀적 방식으로 사용하려는 데이터 사용자의 불편,

나에게 질문은-기본적으로 LinAlg 은 AbstractArray 의 요소가 "스칼라"( Number 의 하위 유형 또는 덕 타이핑)가 될 것으로 예상한다고 선택합니까? 블록 어레이의 복잡성을 외부 패키지로 파밍? 아니면 Base 및 LinAlg 의 복잡성을 수용합니까?

하루 전까지의 계획은 후자였습니다.

@ Sacha0 여기서 변경 사항을 지원하기 위해 필요한 RowVector 작업을 완료하려고했습니다 (이전 작업 비재 귀적 transpose , RowVector 지원 문자열 및 기타 데이터) 지금은 디자인 측면에서 무엇을 염두에 두 셨는지 궁금합니다.

최근 토론에서 원하는 것이 무엇인지 추측하여 이러한 사례를 봅니다.

| | 벡터 | 매트릭스 |
|-|-|-|
| adjoint | RowVector with recursive adjoint | AdjointMatrix 또는 TransposedMatrix with recursive adjoint |
| transpose | RowVector with recursive transpose | TransposeMatrix with recursive transpose |
| flip | 사본 또는 PermutedDimsArray ? | 사본 또는 PermutedDimsArray ? |
| conj / AbstractArray | 게 으르거나 열망합니까? | 게 으르거나 열망합니까? |
| conj / RowVector 또는 TransposedMatrix | 게으른 | 게으른 |

(위에서는 데이터 배열의 순열 차원에서 선형 대수 문제를 분리하려는 시도입니다.)

그래서 몇 가지 기본적인 질문이 있습니다.

• 재귀 적 transpose 있습니까? adjoint 어떻습니까?
• 그렇다면 계속해서 conj(transpose(array)) == adjoint(array) 를 가정할까요?
• 예를 들어 추가 사본없이 모든 현재 BLAS 작업을 지원하기 위해 적어도 일부 복잡한 결합은 게으른 것처럼 보입니다. 모든 어레이에 대해 conj 게으른 상태로 만들까요?
• flip 을 소개하면 게 으르거나 열망합니까?

참고로 나는 permutedims 대해 더 짧은 형식을 사용하여 # 24839에서 행렬의 차원을 "뒤집는"저 마찰 접근 방식을 시도했습니다.

저는 @ Sacha0 의 제안 2를 강력히 찬성합니다. 우리는 재귀 대 비 재귀 adjoint의 이론적 토대를 완전히 분류하지는 않았지만, 그것과는 독립적으로 : 적어도 나에게 유용하다고 판명되었습니다. , 그리고 마지막 순간에 변경하는 것은 아마도 좋지 않을 것입니다. 조옮김은 필요한 경우 이와 관련하여 adjoint (= conj∘adjoint )를 따라야합니다.

FWIW, Mathematica는 Transpose 또는 ConjugateTranspose 재귀를 수행하지 않습니다.

나는 위의 정교한 토론을 읽으려고했지만 어떤 시점에서 수학적 전치가 재귀 적이어야한다고 결정 / 동기화되었는지 확인하지 못했습니다. [...] 완전성 / 자립성을 위해, 그 개념과 그것이 재귀 적이어야하는 이유가 간략하게 반복 / 요약 될 수 있습니까?

이 감정을 이해하고 감사 드리며 시간이 허락하는 한 해결하고자합니다. adjoint 및 transpose가 정의에 따라 재귀 적이어야하는 이유를 액세스 가능하고 명료하게 설명하는 것은 불행히도 기껏해야 어렵고 간략하게는 불가능할 수 있습니다. 위와 같은 일관되고 포괄적 인 글을 작성하는 데는 엄청난 시간이 걸립니다. 시간이 짧기 때문에 하루 동안 특정 요점 / 질문에 응답하여 이전 몇 게시물의 혼란을 해결하려고 노력할 것입니다. 내가 그렇게 단편적인 동안 나를 참아주세요 :). 베스트!

adjoint ... 정의에 따라 재귀 적이어야하는 이유 설명 ...

저는이 토론에 기여한 모든 사람들이 adjoint(A) 이 재귀 적이어야한다는 데 동의합니다. 유일한 논쟁 점은 transpose(A) 도 재귀 적이어야하는지 여부 (그리고 비재 귀적 전치에 대해 새로운 함수 flip(A) 를 도입해야하는지 여부)입니다.

나는이 토론에 기여한 모든 사람들이 adjoint (A)가 재귀 적이어야한다는 데 동의합니다.

예를 들어 https://github.com/JuliaLang/julia/issues/20978#issuecomment-347777577 및 이전 주석을 참조하십시오. :). 베스트!

재귀 적 adjoint에 대한 인수는 정의에서 매우 기본적입니다. dot(x,y) 는 내부 곱이어야합니다. 즉, 스칼라를 생성하고 adjoint의 정의는 dot(A'*x, y) == dot(x, A*y) 입니다. 재귀 ( dot 및 adjoint )는이 두 속성에서 따릅니다.

(내적과의 관계는 선형 대수에서 adjoint와 transpose가 중요한 연산이되는 전체적인 이유입니다. 그것이 우리가 그것들에 대한 이름을 가지고있는 이유이며, 행렬을 90도 회전하는 것과 같은 다른 연산에 대해서는 아닙니다. (Matlab에서는 rot90 ).)

비 재귀 전치에 flip 를 사용할 때의 한 가지 문제는 Matlab과 Numpy가 모두 flipdim 라고 부르는 것에 flip 를 사용한다는 것입니다.

나는 행렬의 전치가 벡터에 작용하지 않고 RowVector에 작용하는 객체가 될 것이라는 단순한 이유 때문에 추상적 인 수학적 의미에서 전치를 실제로 사용하지 않는다고 생각합니다. 즉, RowVector를 매핑합니다. RowVector에.

그러나 일반적인 행렬 방정식에서도 선형 맵의 실제 수학적 전치와 거의 관련이 없다고 생각하기 때문에 재귀 전치를 사용하지 않고 수학이 아닌 응용 프로그램에도 사용할 수 있도록 허용하는 것이 더 간단 해 보입니다.

전치 (수학적 의미에서는 사용되지 않지만 항상 플립 매트릭스 인덱스 의미에서는 사용됨)

이것은 약간 우회적으로 보일 것이므로 저와 함께 참아주세요 :).

Julia의 adjoint 는 특별히 Hermitian adjoint 를 나타냅니다. 일반적으로, 각각의 이중 공간 U * 및 V가있는 U 및 V 완전한 정규 벡터 공간 (Banach 공간) 및 선형 맵 A : U-> V의 경우, 일반적으로 A로 표시되는 A의 인접 요소 는 선형 맵 A입니다. * : V *-> U * . 즉, 일반적으로 adjoint는 이중 공간 사이의 선형 맵입니다. 일반적으로 전치 A ^ t는 위에서 언급 한 이중 공간 사이의 선형 맵입니다. 그렇다면 이러한 정의를 익숙한 Hermitian adjoint 개념과 어떻게 조화시킬까요? :)

대답은 일반적으로 작업하는 공간, 즉 완전한 내부 제품 공간 (Hilbert 공간)이 소유하는 추가 구조에 있습니다. 내적은 규범을 유도하므로 완전한 내적 공간 (Hilbert)은 완전한 규범 공간 (Banach)이므로 (Hermitian) adjoint의 개념을 지원합니다. 핵심은 다음과 같습니다. 단순한 표준이 아닌 내적을 갖는 선형 대수에서 가장 아름다운 정리 중 하나, 즉 Riesz 표현 정리가 적용됩니다. 간단히 말해서, Riesz 표현 정리는 Hilbert 공간이 자연적으로 이중 공간과 동형이라고 말합니다. 결과적으로 Hilbert 공간으로 작업 할 때 일반적으로 공간과 쌍대를 식별하고 구별을 삭제합니다. 그러한 식별을하는 것은 A * : V *-> U *가 아닌 A * : V-> U로 친숙한 Hermitian adjoint 개념에 도달하는 방법 입니다.

그리고 Hilbert 공간을 고려할 때 전치에 대해 동일한 식별이 일반적으로 이루어지며, A ^ t : V-> U도 익숙한 전치 개념을 산출합니다. 그래서 명확히하기 위해, 예, 전치의 일반적인 개념은 가장 친숙한 (Hilbert) 설정에 적용된 전치의 일반적인 개념입니다. Hermitian adjoint의 일반적인 개념이 해당 설정에 적용된 adjoint의 일반적인 개념 인 것처럼 말입니다. 베스트!

죽은 말을 쳐서 미안하지만 수학적 혼란의 문제를 다른 방식으로 간략히 요약하겠다고 생각했습니다. 불일치의 요점은 T 가 배열과 같은 하위 구조가없는 Number 의 하위 유형이 아닌 경우 Vector{T} 개체를 수학적으로 해석하는 방법입니다.

한 학파는 @stevengj 의 주장을 받아들입니다.

링 R 위의 벡터 벡터는 직접 합계 공간으로 가장 잘 이해되며 R 위의 벡터 공간이기도합니다.

무한 차원 벡터 공간 등에 관한 특정 미묘함을 모듈로 화하면 기본적으로 벡터의 벡터를 블록 벡터로 생각해야 함을 의미합니다. 따라서 Vector{Vector{T<:Number}} 는 정신적으로 단순한 Vector{T} 로 "평탄화"되어야합니다. 이 패러다임 내에서 행렬의 행렬로 표현되는 선형 연산자는 블록 행렬로 유사하게 간주되어야하며 adjoint 는 확실히 재귀 적이어야합니다. transpose 에서 단어를 사용하는 경우 수학적 의미 . 제가 틀렸다면 저를 고쳐주세요.하지만 이런 관점을 취하는 사람들은 Vector{Matrix{T}} 같은 것은 우리가 디자인해야 할 자연스럽고 충분한 해석이 없다고 생각합니다. (특히 @stevengj가 말했듯이 내부 Matrix 가 복소수의 행렬 표현이라고 가정해서는 안됩니다.

2x2 행렬로 복소수를 표현하는 경우 복잡한 벡터 공간이 다릅니다.

)

또 다른 생각은 Vector{T} 는 T 유형의 스칼라 (단어의 선형 대수적 의미에서) 위에 추상적 인 벡터 공간에있는 벡터의 표현으로 항상 생각되어야한다는 것입니다. T 유형에 관계없이. 이 패러다임에서 Vector{Vector{T'}} 는 직접 합계 공간의 요소가 아니라 스칼라 Vector{T'} 의 벡터로 간주되어야합니다. 이 경우에는 transpose(Matrix{T}) 재귀 안되며, 단순히 외부 매트릭스를 반전한다. 이 해석의 한 가지 문제는 T 유형의 요소가 유효한 스칼라 링을 형성하기 위해서는 (교환) 덧셈 및 곱셈에 대한 잘 정의 된 개념이 있어야한다는 것입니다. Vector{Vector{T'}} 와 같은 벡터의 경우 두 개의 "스칼라" Vector{T'} 를 다른 Vector{T'} 에 곱하는 규칙이 필요합니다. 확실히 그러한 규칙 (예 : T' 를 곱하는 방법에 대한 문제를 해결하는 요소 별 곱셈)을 생각 해낼 수 있지만, 그렇게하는 보편적 인 자연스러운 방법은 없습니다. 또 다른 문제는이 해석에서 adjoint 가 작동하는 방식입니다. Hermitian adjoint 는 정의에 따라 스칼라 필드 가 실수 또는 복소수 여야하는 Hilbert 공간에 대한 선형 연산자에서만 정의됩니다. 따라서 adjoint 을 행렬 Matrix{T} 에 적용하려면 T 이 복소수 (또는 실수)를 표현한다고 가정해야합니다. 그 케이스가 더 미묘하기 때문에 복잡합니다). 이 해석에서, adjoint 재귀하지 않아야하지만, 외부 매트릭스를 뒤집어해야하고 적용 conjugate . 그러나 여기에는 더 많은 문제가 있습니다. conjugate(T) 의 올바른 동작은 표현의 특성에 따라 달라지기 때문입니다. 위키피디아에 설명 된 2x2 표현이라면 conjugate 는 행렬을 뒤집어 야합니다. 그러나 위에서 설명한 이유 때문에 conjugate 가 항상 행렬을 뒤집어서는 안됩니다. 따라서이 접근 방식은 구현하기가 약간 엉망입니다.

내 생각은 다음과 같습니다. 요소가 더 복잡한 하위 구조를 갖는 배열에 적용 할 때 transpose 이 재귀 적이어야하는지 여부에 대한 "객관적으로 올바른"대답은 없습니다. 사용자가 Julia에서 추상 대수 구조를 얼마나 정확하게 표현하기로 선택하는지에 따라 다릅니다. 그럼에도 불구하고 완전히 임의의 스칼라 링을 지원하는 것은 매우 어려울 것 같아서, 실용성을 위해 그렇게 야심 차게 시도해서는 안되며 비표준 링에 대한 모듈의 난해한 수학을 잊어야한다고 생각합니다. 우리는 분명히 Base ( permutedims(A, (2,1)) 보다 간단한 구문을 가진) 함수가 있어야합니다.이 함수는 전치의 선형 대수 개념과 관련이없고 단순히 행렬을 뒤집고 재귀 적이 지 않은지 여부에 관계없이 아무것도하지 않습니다. transpose 또는 flip 또는 뭐라고합니다. 그것은 좋은 경우가 될 것이다 adjoint 와 (아마도 다른 이름) 별도의 전치 기능 LinAlg 그 때 블록 벡터 / 행렬과 직접 합계의 간단한 구현을 처리 할 수 있기 때문에, 재귀했다 그러나 이것은 "객관적인 수학적 정확성"에 의해 요구되지 않으며, 순전히 구현의 용이성에 근거하여 결정을 내리는 것이 좋습니다.

더 이상 언급하지 않겠다는 이전의 약속에도 불구하고 불행히도 이에 응답해야합니다.

Julia의 adjoint는 특히 Hermitian adjoint를 나타냅니다. 일반적으로, 각각의 이중 공간 U * 및 V가있는 U 및 V 완전한 정규 벡터 공간 (Banach 공간) 및 선형 맵 A : U-> V의 경우 일반적으로 A로 표시되는 A의 에르 미트 식 adjoint 는 선형 맵입니다. A * : V *-> U *. 즉, 일반적으로 전치 A ^ t가 위에서 언급 한 이중 공간 사이의 선형 맵인 것처럼 일반적으로 Hermitian adjoint는 이중 공간 간의 선형 맵입니다. 그렇다면 이러한 정의를 익숙한 Hermitian adjoint 개념과 어떻게 조화 시키십니까? :)

그것은 사실이 아닙니다. 여기에서 설명하는 것은 실제로 전치이지만 (이미 언급했듯이) 일부 분야에서는이를 adjoint (Hermitian 제외)라고하며 A ^ t 또는 A ^ * (A ^ dagger 아님)로 표시됩니다. 사실, 그것은 벡터 공간을 훨씬 넘어서 확장되며, 범주 이론에서 그러한 개념은 모든 단일체 범주 (예 : 선형 맵으로 cobordisms가있는 n 차원 지향 매니 폴드의 범주 Cob)에 존재하며, 여기서 adjoint mate (in 사실 왼쪽과 오른쪽 이중 공간이 반드시 동일하지는 않기 때문에 두 개의 다른 A와 A 가있을 수 있습니다.) 그러나 이것은 복잡한 결합을 포함하지 않습니다. V *의 요소는 실제로 선형 맵 f : V-> Scalar이며 선형 맵 A : U-> V 및 U의 벡터 v에 대해 f (Av) = (A ^ tf) (v) . f의 작용은 복잡한 켤레를 포함하지 않기 때문에 A ^ t의 정의도 마찬가지입니다.

대답은 일반적으로 작업하는 공간, 즉 완전한 내부 제품 공간 (Hilbert 공간)이 소유하는 추가 구조에 있습니다. 내적은 규범을 유도하므로 완전한 내적 공간 (Hilbert)은 완전한 규범 공간 (Banach)이므로 Hermitian adjoint의 개념을 지원합니다. 핵심은 다음과 같습니다. 단순한 표준이 아닌 내적을 갖는 선형 대수에서 가장 아름다운 정리 중 하나, 즉 Riesz 표현 정리가 적용됩니다. 간단히 말해서, Riesz 표현 정리는 Hilbert 공간이 자연적으로 이중 공간과 동형이라고 말합니다. 결과적으로 Hilbert 공간으로 작업 할 때 일반적으로 공간과 쌍대를 식별하고 구별을 삭제합니다. 그 식별을하는 것은 당신이 A * : V *-> U *가 아닌 A * : V-> U와 같은 Hermitian adjoint의 익숙한 개념에 도달하는 방법입니다.

다시 말하지만 나는 그것이 완전히 옳다고 생각하지 않습니다. 내적 공간에서 내적은 conj (V) x V-> 스칼라 (conjugate 벡터 공간 인 conj (V) 사용)에서 dot 형식입니다. 이것은 실제로 V에서 V *로 (또는 기술적으로는 conj (V)에서 V *로) 맵을 설정할 수있게하는데, 이는 실제로 Riesz 표현 정리입니다. 그러나 Hermitian adjoint를 도입하는 데는 필요하지 않습니다. 실제로 내적 dot 만으로도 충분하며 선형 맵 A 의 Hermitian adjoint는 다음과 같습니다.
dot(w, Av) = dot(A' w, v) 여기에는 복잡한 활용이 포함됩니다.

그것은 사실이 아닙니다. 여기에서 설명하는 것은 실제로 전치이지만 (이미 언급했듯이) 일부 분야에서는이를 adjoint (Hermitian 제외)라고하며 A ^ t 또는 A ^ * (A ^ dagger 아님)로 표시됩니다. [...]

@Jutho , 예를 들어 Hermitian adjoint 의

다른 수학 분야간에 불일치가있을 수 있지만 :
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map
특히
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map#Relation_to_the_Hermitian_adjoint
그리고 카테고리 이론에서 셀 수없이 많은 참고 문헌, 예를 들어
https://arxiv.org/pdf/0908.3347v1.pdf

https://en.wikipedia.org/wiki/Transpose_of_a_linear_map
특히
https://en.wikipedia.org/wiki/Transpose_of_a_linear_map#Relation_to_the_Hermitian_adjoint

@Jutho , 해당 페이지 섹션과 위에서 링크 한 페이지에 제공된 정의 사이에 불일치가 없으며 위에 게시 한 내용과 일치하지 않는 것도 볼 수 없습니다. 베스트!

나는 또한 @ Sacha0 의 제안 2에 서명 할 것이다. 나는 1 인수 permutedims 괜찮다. flip 보다 낫다고 생각합니다.

@ Sacha0 이면 그것을 해석하는 다른 방법이 있습니다. 나는 이것을 읽었다
주어진 A : U-> V에 대해,
transpose (A) = dual (A) = (때로는 또한) adjoint (A) : V *-> U *
hermitian adjoint (A) = dagger (A) = (일반적으로 just) adjoint (A) : V-> U
그리고 둘 사이의 관계는 복잡한 활용을 포함하는 공간에서 이중 공간 (즉, Riesz ...)으로의 맵을 사용하여 정확하게 얻습니다. 따라서 hermitian adjoint는 활용을 포함하고 전치하지 않습니다.

첫 번째 은둔자 adjoint라고 부르고 싶다면 무엇을 전치라고 부릅니까? 설명에있는 내용을 실제로 정의하지 않았습니다. 방금 언급했습니다.

일반적으로 A로 표시되는 A의 Hermitian adjoint는 선형 맵 A : V *-> U *입니다. 즉, 일반적으로 전치 A ^ t가 이중 공간 사이의 선형 맵인 것처럼 일반적으로 Hermitian adjoint는 이중 공간 사이의 선형 맵입니다.

그래서 전치와 Hermitian이 인접하면 A : U-> V를 V- > U 에서 맵으로 변환하는 두 가지 다른 방법이 있습니까? 이에 대해 더 논의하게되어 기쁩니다.하지만 다른 곳에서하는 것이 더 좋을 것 같습니다. 그러나 실제로 이것에 대해 더 많은 것을 배우고 싶기 때문에 저에게 연락하십시오.

또한 Banach 공간의 맥락에서 사용되는 인접하는 참조는 http://staff.um.edu.mt/jmus1/banach.pdf 를 참조

Julia Base의 경우 : 저는 재귀 Hermitian 활용에 반대하지 않습니다. 나는 그것이 종종 올바른 일이라는 데 동의합니다. 요소 유형이 Number 이 아닐 때 Base가 영리한 작업을 시도해야할지 모르겠습니다. T is number라고해도 Base에서 비 유클리드 내부 제품 (및 관련 수정 된 adjoint 정의)의 훨씬 더 일반적인 사용을 지원하지 않으며, 있어야한다고 생각하지도 않습니다. 그래서 주된 동기는 블록 행렬이라고 생각합니다.하지만 거기에서는 특수 목적 유형 (Base 또는 패키지)이 훨씬 더 Julian이라고 생각합니다. @andyferris 도 언급했듯이 나머지 LinAlg 와는 다릅니다. LinAlg 는 블록 행렬의 개념을 지원합니다. 심지어 inv (행렬 분해 등은 제외)와 같은 간단한 것까지도 지원합니다.

그러나 재귀 Hermitian 활용이 여기에 머물러 있다면 (좋습니다), 일관성을 위해 dot 및 vecdot 가 요소에 대해 재귀 적으로 작동해야한다고 생각합니다. 현재는 그렇지 않습니다. dot 는 요소에 대해 x'y 를 호출하고 (요소가 행렬 인 경우 동일하지 않음) vecdot 는 dot 호출합니다. 요소에. 따라서 행렬 벡터의 경우 실제로 스칼라 결과를 얻을 수있는 방법이 없습니다. 사람들이 현재 구현이 재귀 적 adjoint 과 실제로 일치하지 않는다는 데 동의한다면 PR을 준비하게되어 기쁩니다.

transpose 경우 비재 귀적으로 만들고 숫자 데이터로 작동하지 않는 사람들이 사용하도록하는 것이 더 간단 해 보입니다. 나는 행렬로 작업하는 대부분의 사람들이 transpose 라는 용어를 알고 있으며 그것을 찾을 것이라고 생각합니다. 재귀 transpose 가 필요한 사람들을 위해 여전히 conj(adjoint()) 가 있습니다.

Triage는 @ Sacha0 이 제안 2를 진행하여 시도해 볼 수 있다고 생각합니다.

나는 재귀 적 adjoint가 수학적으로 일관된 유일한 옵션이 아니라 선택이라는 @ttparker에 강력하게 동의합니다. 예를 들어 다음과 같이 간단히 설명 할 수 있습니다.

1- LinAlg , AbstractVector v 는 (스칼라) 기본 가중치가있는 length(v) 차원 벡터입니다. v[1] , v[2] , ..., v[length(v)] .

(그리고 유사하게 AbstractMatrix ).

이것은 아마도 많은 사람들이 다른 라이브러리에서 오는 가정 일 것이며, 기본 벡터, 순위 등의 간단한 정의를 갖는 것은 구현을 단순하게 유지하는 데 도움이됩니다. (많은 사람들이 수치 선형 대수를 컴퓨터에서 정확하게 구현할 수 있다고 말할 것입니다. 왜냐하면 우리가 작업하기에 좋은 기준이 있기 때문입니다.)

현재의 접근 방식은 다음과 같습니다.

2- LinAlg , AbstractVector v 는 length(v) 추상 벡터의 직접 합계입니다. 또한 Number 와 같은 스칼라 유형에 대한 충분한 정의를 포함하여 LinAlg 까지 유효한 1 차원 선형 연산자 / 벡터가됩니다.

마찬가지로 (블록) 행렬에 대해서도 마찬가지입니다. 이것은 MATLAB, numpy, eigen 등의 선형 대수 구현보다 훨씬 더 일반화되었으며, 이것이 실현 가능하다는 Julia의 강력한 유형 / 디스패치 시스템을 반영한 것입니다.

내가 옵션 2 가 바람직하다고 보는 가장 중요한 이유는 Julia의 유형 / 파견 시스템을 통해 훨씬 더 광범위한 목표를 가질 수 있다는 점입니다.

3- LinAlg 에서는 + , * , conj 아래의 선형성을 충족하는 객체 (등)에 대해 작동하는 일반 선형 대수 인터페이스를 만들려고합니다

정말 멋진 목표 (내가 알고있는 다른 프로그래밍 언어 / 라이브러리보다 훨씬 뛰어남)는 완전히 재귀 adjoint 및 2에 동기를 부여합니다 ( + , * 그리고 conj 자체가 재귀)와 Sacha0의 제안이와 선별 결정이 좋은 선택 인 이유 @입니다 :)

이에 대해 더 논의하게되어 기쁩니다.하지만 다른 곳에서하는 것이 더 좋을 것 같습니다. 그러나 실제로 이것에 대해 더 많은 것을 배우고 싶기 때문에 저에게 연락하십시오.

건배합시다! 나는 더 오프라인에서 채팅을 기대합니다 :). 베스트!

멋진 요약 Andy! :)

Andy는 최소한 adjoint (댓글의 주제)에 완전히 동의했습니다.

그러나 내가 영원히 평화를 유지하기 전에 비재 귀적 transpose 대한 마지막 탄원입니다.
다음과 같은 장점이있는 비 재귀 전치가 있습니다.

• 숫자가 아닌 데이터를 포함하여 행렬을 사용하는 모든 사람들이 사용할 수 있습니다. 그것은 또한 다른 언어와 비수 치적 사용 사례로 추정 된 기본 수학에서이 연산을 알고 찾는 방법이기도합니다.

• 게으른 flip 유형 또는 PermutedDimsArray 가 LinAlg 와 상호 작용하도록 추가 코드를 작성할 필요가 없습니다. 전치하는 대신 뒤집은 숫자 행렬이 있다면 어떨까요? 그래도 다른 행렬과 곱할 수 있습니까 (바람직하게는 BLAS 사용)?

• 비 재귀 transpose 및 재귀 adjoint 하면 conj(transpose(a)) 및 재귀 전치 conj(adjoint(a)) 와 같은 비 재귀 adjoint를 쉽게 가질 수 있습니다. 그리고 여전히 모든 것이 LinAlg 와 잘 상호 작용합니다.

그래서 단점은 무엇입니까? 나는 아무도 보지 않는다. 나는 아직도 그 누구도 수학적 의미에서 transpose 를 사용하지 않는다는 내 주장을지지합니다. 그러나 더 이상 논쟁을 시도하는 대신 재귀 전치가 필요하거나 유용하며 실제로 수학적 tanspose 인 구체적인 예를 누가 줄 수 있습니까? 여기에는 실제로 adjoint 하려고했지만 실수 만있는 예는 제외됩니다. 따라서 그 자체가 복잡한 값인 더 많은 행렬로 채워진 벡터 또는 행렬을 전치하는 수학적 이유가있는 응용 프로그램입니다.

적어도 Mathematica (이에 대해 상당한 생각을했을 것으로 예상되는)는 재귀 전치를하지 않는다고 말할 수 있습니다.

A = Array[1 &, {2, 3, 4, 5}];
Dimensions[A]  # returns {2, 3, 4, 5}
Dimensions[Transpose[A]] # returns {3, 2, 4, 5}

편집 : 죄송합니다, 이것은 또한 위에 언급되었습니다.

그래서 혼란 스럽습니다. transpose 는 비재 귀적으로 만들어야한다는 매우 확실한 합의가있는 것 같습니다. 예 : https://github.com/JuliaLang/julia/issues/20978#issuecomment -285865225, https://github.com/ JuliaLang / julia / issues / 20978 # issuecomment -285942526, https://github.com/JuliaLang/julia/issues/20978#issuecomment -285993057, https://github.com/JuliaLang/julia/issues/20978#issuecomment- 348464449 및 https://github.com/JuliaLang/julia/pull/23424. 그런 다음 @ Sacha0 은 두 가지 제안을했습니다. 그 중 하나는 재귀 전치 상태를 유지하지만 비 재귀 flip 함수를 도입했습니다. 이는 이전에 실제로 가능성이 제기되지 않았음에도 불구하고 강력한 지원을 받았습니다. . 그런 다음 @JeffBezanson 은 permutedims 에 기본 두 번째 인수를 주면 결국 flip 가 필요하지 않다고 제안했으며, 이는 또한 강력한 지원을 받았습니다.

따라서 이제 합의는 transpose 의 유일한 실제 변경 사항이 "뒤에서"여야한다는 것입니다. 일반적인 최종 사용자는 아마 알지 못하거나 신경 쓰지 않을 것입니다. . 실제로 눈에 띄는 유일한 변경 사항은 기본적으로 철자 변경뿐입니다 ( .' 감가 상각 및 permutedims 기본 두 번째 인수 제공).

따라서 커뮤니티 합의는 매우 짧은 시간 ( @ Sacha0 의 게시물 https://github.com/JuliaLang/julia/issues/20978#issuecomment-347360279

누군가가 이것을 제안했는지 잊어 버렸습니다.하지만 transpose(::AbstractMatrix{AbstractMatrix}) (그리고 아마도 transpose(::AbstractMatrix{AbstractVector}) 도 가능) 재귀 적으로 만들 수 있고 그렇지 않으면 transpose 비재 귀적으로 만들 수 있습니까? 그것은 모든 기초를 다룰 것 같고 tranpose 가 재귀 적이기를 원하는 다른 사용 사례를 생각할 수 없습니다.

따라서 커뮤니티 합의는 매우 짧은 시간 ( @ Sacha0 의 게시물 # 20978 (댓글) 즈음)에 거의 180도 변경된 것 같습니다. Sacha의 게시물이 너무 웅변해서 모든 사람의 마음을 바꿨나요? (그렇다면 괜찮습니다. 며칠 전만해도 우리 모두가 틀렸다는 데 동의하는 것처럼 보였던 경로를 앞으로 나아가는 것처럼 보이는 이유를 이해하고 싶습니다.)

내가 그렇게 설득력이 있다면 😄. 당신이보고있는 것은 합의가 실제로 형성되지 않았다는 것입니다. 오히려, (1) 현상 유지를 선호하지만 소모로 인해 토론에서 철회 한 참가자는 의견을 표명하기 위해 돌아 왔습니다. (2) 현상 유지에서 벗어나는 것이 실제로 어떤 일을 수반하는지 (그리고 그것이 해제 고려 사항과 어떻게 작용할 수 있는지) 고려하지 않은 다른 당사자들은 현상 유지에 찬성하여 더 강력한 의견을 형성하고 그 의견을 표명했습니다.

이 토론은 2014 년부터 github에서 어떤 형태로든 진행되었으며, 아마도 그 이전에는 오프라인 일 가능성이 높습니다. 장기 참가자의 경우 이러한 토론은 지루하고 주기적으로 진행됩니다. 이 토론에 참여하는 것 외에 더 즐거운 코드 작성과 같은 의미있는 작업이 있다는 것은 그 결과 장기 참가자들 사이에서 손실을 초래합니다. 결과적으로 대화는 한 기간 또는 다른 기간 동안 일방적으로 나타납니다. 개인적으로 저는 그 소모 임계 값에 이르렀으므로이 토론에 계속 참여하기보다는 지금 코드 작성에 집중할 것입니다. 모두 감사합니다! :)

나는 AbstractArray에 대한 비 재귀 전치와 ctranspose에 찬성하여 작은 투표를 할 것입니다. 둘 다 AbstractArray {T}에서 재귀 적입니다. 여기서 T <: AbstractArray.

나는 재귀 적 행동이 어떤 경우에 '올바른'것에 동의하며, 패키지를 사용하고 개발하는 사람들에게 최소한의 놀라움으로 올바른 행동을 어떻게 달성 할 수 있는지에 대한 질문을 봅니다.
이 제안에서 사용자 정의 유형에 대한 재귀 전치 동작은 옵트 인입니다. 유형을 AbstractArray로 만들거나 적절한 메서드를 정의하여 옵트 인합니다.
Base.transpose(AbstractArray{MyType}) 또는 Base.transpose(AbstractArray{T}) where T<: MyAbstractType .
재귀 전치에 대한 덕 타이핑 전략 (물어 보지 않고 그냥 반복)은 위에서 설명한대로 몇 가지 놀라움을 생성한다고 생각합니다. 별개의 ctranspose 및 adjoint를 도입하거나 conjadjoint 및 flip과 같은 더 복잡한 제안을 도입하면 사용자는 이러한 제안을 접하고 사용하려고 할 것이며 패키지 관리자는 모두 지원하려고 할 것입니다.

새로운 제안에서 지원하기 어려운 것의 예로 normal, transpose, ctranspose 및 conj 배열은 모두 ReshapedArray 및 SubArray보기와 상호 작용하는보기 (또는 지연 평가)를 가질 수 있어야합니다. (저는 이것이 기본적으로 뷰를 생성하는지 아니면 @view 사용할 때만 생성되는지에 대해 궁금합니다.) 이것은 A*_mul_B* 낮추는 작업과 플래그 'N'을 사용하는 낮은 수준의 BLAS 호출에 연결됩니다. 다른 곳에서 언급 한 바와 같이 고밀도 어레이의 경우 'T'및 'C'. normal , transpose , ctranspose , conj 를 취급했다면 추론하기가 더 쉬울 것입니다.
동등한 기반에. BLAS 자체는 일반의 경우 'N', 전치의 경우 'T', ctranspose의 경우 'C'만 지원하며 conj에 대한 플래그가 없습니다. 이것은 실수라고 생각합니다.

마지막으로, 더 높은 차원의 배열 및 모양 변경과의 일관성을 위해 전치 및 c 전치의 적절한 일반화는 모든 차원을 반전하는 것입니다.
transpose (A :: Array {T, 3}) = permutedims (A, (3, 2, 1)).

건배!

실제로 일을하는 사람들에게 정말 감사합니다. 어떤 방법에서 논의 된 것은 @andyferris이 강화이 구현 될 때까지 너무 많은 길이는 벡터 유사한 내용 / 전치 (그러나 결코 그것의 재귀 적 측면)이며, 멋지고 잘 작동합니다. 마찬가지로, 배열 생성자의 지속적인 재 설계도 매우 감사합니다. 그 모든 것에 엄지 손가락.

즉, 행렬 전치 및 adjoint / ctranspose는 단일 동기 블록 행렬로 https://github.com/JuliaLang/julia/pull/7244 에서 거의 조용히 소개 된 재귀 적 측면에서 많은 논의를 얻지 못했습니다. . 재귀 적 adjoint에 대한 다양한 이유와 동기가 주어졌고 (사실 이후) 대부분의 사람들은 이것이 좋은 (유일한 것은 아님) 선택이라는 것에 동의 할 수 있습니다. 그러나 Transpose에는 단일 동기 또는 실제 사용 사례조차 부족합니다.

이 토론에서는 몇 가지 별도의 작업이 진행되고 있으며, 신속하게 구현할 수있는 계획이 필요합니다.

• 우리는 LinAlg 에서 블록 행렬 (및 더 이국적인 구조)을 지원하는 것이 가치가 있는지 논의했습니다. 구현 선택 사항은 다음과 같습니다. 재귀 적 요소 없음 ( + , * 및 conj 제외), 모든 재귀 적 요소 (Julia의 일반 함수 특성), 또는 요소가 재귀 선형 대수를 수행해야하는지 또는 스칼라로 처리되어야하는지 여부에 대한 일종의 유형 검사 또는 특성을 시도합니다.
• 우리는 사용자가 2D 데이터 배열의 차원을 변경할 수있는 좋은 방법을 원합니다. 비재 귀적 transpose , flip , 단축 된 permutedims 구문이 있습니다 (이 PR은 구현할 문자 수가 가장 적기 때문에 먼저 제출되었으며 만약 우리가 다른 일을한다면), 요소가 재귀 전치 (recursive transpose)를해야하는지 여부에 대한 일종의 유형 검사 나 특성 (아마도 transpose(x::Any) = x ...).
• Julia 파서는 x' * y -> Ac_mul_B(x, y) 와 같은 이상한 동작을 가지고 있습니다. 이것은 이상적으로 v1.0에는 존재하지 않는 약간의 사마귀입니다. 이것은 빠른 BLAS (추가 사본 없음)를 지원할 수있을 때까지 실행 가능한 것으로 간주되지 않았으므로 지연 행렬 전치 및 인접합니다.
• LinAlg 의 코드는 상당히 크고 수년에 걸쳐 구축되었습니다. 행렬 곱셈과 같은 많은 것들은 아마도 새로운 broadcast 와 같은 디스패치 시스템을 사용하여 더 특성 친화적으로 리팩토링 될 수 있습니다. 이것이 바로 올바른 배열 (스트라이드 행렬의 변형 된 변형 된 뷰의 PermuteDimsArray를 생각하고 있습니다)을 BLAS로 더 쉽게 보낼 수있는 곳이라고 생각합니다. 그러나 이것은 v1.0을 만들지 않을 것이며 우리는 코드를 훨씬 더 악화시키지 않으면 서 성능 회귀를 피하려고 노력하고 있습니다. Sacha가 지적했듯이 요소 (재귀 적 인접, 재귀 전치, 활용, 아무것도 없음)에 대한 다양한 동작을 가진 전치 뷰를 갖는 것은 일을 계속 작동시키는 추가 복잡성과 새로운 방법을 만듭니다. 아르.

v1.0이 언어를 어느 정도 안정화시키는 것으로 생각한다면 어떤 의미에서 행동을 변경하는 가장 큰 우선 순위는 세 번째입니다. 나는 말하고 싶다 : 언어 (파서 포함)는 가장 안정적이어야하고 Base 다음으로 stdlib ( LinAlg 포함하거나 포함하지 않을 수 있음)가 뒤 따르지만 거의 확실하게 포함 될 것이라고 생각합니다. BLAS , Sparse 등 1 일). 사용자 (대부분 도서관 개발자)에게 실제로 영향을 미치지 않는 변화이므로 여기에서 사람들의 의견이 다르더라도 놀라지 않을 것입니다.

Andy를 찾아라! :)

여기서 남은 것은 기본적으로 adjoint 와 transpose 게으르게 만드는 것 뿐이라고 생각합니다.

지금 닫을 수 있습니까?

다음 단계 : "스칼라 사용은 심각하게 전치합니다."

그러나 진지하게, PDE 솔버에서 사용되는 다른 3D 전치 및 텐서 곱셈을 지정하기위한 좋은 인터페이스를 가질 수 있습니까? 진지하지만,이 광기의 다음 반복의 OP가 될 수 있을지 잘 모르겠습니다.

아니

:)

PDE 솔버에서 사용되는 다른 3D 전치 및 텐서 곱셈을 지정하기위한 좋은 인터페이스를 가질 수 있습니까?

확실히 패키지의 좋은 주제 인 것 같습니다.

다른 3D 전치 및 텐서 곱셈을 지정하기위한 좋은 인터페이스

TensorOperations.jl 이 여기서 필요한 작업을 수행하지 않습니까? (이 수준에서 "좋은 인터페이스"는 Tensor 네트워크 다이어그램과 같은 것을 의미하며 TensorOperations 의 구문보다 간결하게 코드를 작성하기가 약간 어렵습니다.)

예, TensorOperations.jl이 좋아 보입니다. 농담 이었지만 필요한 것을 얻었습니다 👍.