Julia: 베이스 내부 제품 상태

사용 사례에 대해 조금 더 설명하고 패키지에 정의하는 대신 Base에 두는 것이 유익한 이유를 설명해 주시겠습니까? 구체적인 예가 가장 좋습니다. 동시에 로드된 패키지에서 여러 inner 정의가 필요합니까?

이러한 수학적 공간에 대한 공식 인터페이스를 갖는 것이 사용자가 유형 시스템을 더 잘 활용하는 데 도움이 될 것이라고 생각합니다. 예를 들어, 클러스터링 방법이 모든 메트릭 공간에서 작동할 것으로 예상합니다. 내 유형을 내부 제품으로 정의할 수 있다면 즉시 Clustering.jl 의 이점을 얻을 수 있습니다(패키지가 그에 따라 수정된 후). 다른 많은 거리 기반 또는 투영 기반 알고리즘도 일반화할 수 있습니다.

구체적인 예로 오늘 구성 데이터에 대한 지오메트리를 정의하려고 시도하면서 이 제한 사항을 발견했습니다. https://github.com/juliohm/CoDa.jl 차라리 잘 알려진 inner 함수를 전문으로 하고 싶습니다. 다른 사람이 알지 못하는 내 자신의 인터페이스를 정의하는 것보다 Base에 정의되어 있습니다.

Hilbert 공간 유형에 대해 dot 를 확장하지 않는 이유는 무엇입니까? 나는 그것이 일반적인 내부 제품을 염두에두고 설계되었다고 확신합니다.

내적의 개념보다 내적의 개념이 더 엄격합니다. 후자는 일반 공간에 대해 정의되지만 내적은 유한 기반으로 정의되는 좌표계의 개념이 있을 때만 정의됩니다. dot(x,y) 의 의미는 x'*y 입니다. 여기서 x 및 y 는 데카르트 세계에서 객체의 좌표 를 나타냅니다. 저자는 일반적으로 더 일반적인(반드시 유한하거나 유클리드가 아닌) 공간에서 자료를 다루는 데 관심이 있기 때문에 수학 교과서에서는 내적이라는 용어를 거의 언급하지 않습니다.

더 구별하기 위해 내적 <x,y> (또는 inner(x,y) )를 갖는 힐베르트 공간에서 객체는 무한할 수 있고 의미론 x'*y 은 적용되지 않습니다. 예를 들어, 기능 데이터 분석에서 객체는 f 및 g 함수이고 내부 제품은 일반적으로 수치 적분( inner(f,g) = quadrature(f*g) )을 통해 얻습니다. 이 연산을 내적이라고 부르는 것은 오해의 소지가 있습니다.

CoDa.jl 패키지에서 지적한 또 다른 예는 구성 데이터입니다. 컴포지션 개체는 x'*y 작업이 의미가 없는 단순 세계에 있습니다. 그러나 컴포지션을 좌표와 함께 내적을 적용할 수 있는 다른 기하학으로 매핑하는 데 사용할 수 있는 등축 변환(로그 비율 변환)이 있습니다. 좌표로 작업할 필요는 없지만 이 분야에서는 일반적입니다. 결과는 객체가 존재하는 원래 공간으로 다시 변환될 수 있습니다.

언어에서 dot 라는 용어를 유지하는 데 이점이 없다고 생각하지만 이전 버전과의 호환성을 요청하면 일반화 inner(x::AbstractVector, y::AbstractVector) = dot(x,y) 가 완벽하게 작동합니다.

이 변경에 대한 반대 의견에 대해 자세히 설명해 주시겠습니까?

이 변경에 대한 반대 의견에 대해 자세히 설명해 주시겠습니까?

우리는 일반적으로 Base에 새로운 공공 기능을 추가하기 위해 상당한 양의 정당성을 요구합니다. 그것이 반대입니다. 이것은 InnerProducts 패키지에서 제공할 수 있습니다. 왜 언어 자체에 내장되어야 합니까? 이것은 @andreasnoack 이 위에서 질문한 첫 번째 질문이었습니다. "이러한 수학적 공간에 대한 형식적인 인터페이스를 갖는 것이 사용자가 유형 시스템을 더 잘 활용하는 데 도움이 될 것이라고 생각합니다"라는 다소 모호한 대답을 얻었습니다. 패키지에 정의된 인터페이스가 Base에 정의된 인터페이스보다 덜 형식적일 이유가 없습니다. Base.inner 가 있으면 InnerProducts.inner 가 제공하지 않는 것은 무엇입니까? 이것은 설득력 있는 대답을 가질 수 있는 진정한 질문이지만 그 대답이 무엇일지 모르기 때문에 질문을 받는 것입니다.

나는 Base가 아닌 다른 곳에서 내적과 같은 기본적인 수학적 개념을 정의하는 좋은 주장을 보지 못했습니다. 주요 청중이 과학 컴퓨팅 사용자인 언어는 올바른 용어를 사용하는 것이 좋습니다. norm Base.LinAlg 에 정의되어 있고 같은 코호트에 있는 inner 가 패키지에 정의되어야 하는 이유는 무엇입니까? 이러한 불일치 외에도 언어에는 이미 dot 가 있습니다. 그래서 왜 더 일반적인 개념이 아니라 특정한 것을 가져야 하는지 궁금합니다.

기본 언어로 가능한 모든 수학적 개념을 원하십니까? Base에 정의된 것이 없다고 해서 사람들이 잘못된 용어를 사용하도록 강요하지는 않습니다. norm 함수는 LinAlg 에서 정의되고 사용되기 때문에 LinAlg 에서 내보냅니다. dot 와 유사합니다. dot 의 이름을 inner 로 바꿔야 한다고 제안하시겠습니까?

기본 언어로 가능한 모든 수학적 개념을 원하십니까?

나는 절대로 그렇게 말하지 않았다.

Base에 정의된 것이 없다고 해서 사람들이 잘못된 용어를 사용하도록 강요하지는 않습니다.

그렇지 않다고 확신합니다. 잘못된 용어를 조장하는 것이 문제입니다. 수학적 배경이 덜한 사람들은 Base에서 점을 보기 때문에 점 사용법을 채택할 것입니다. 내적의 개념을 나타내는 "내적"이라는 용어의 사용은 올바르지 않습니다. 또한 잘못된 용어가 남긴 이러한 흉터를 수정하기 위해 때때로 고군분투하는 수학 커뮤니티에도 해롭습니다. 제 세대의 학생들은 용어를 올바르게 이해하기 위해 지속적으로 오래된 책을 참조해야 합니다. 이것은 사실이 아니어야 합니다.

점의 이름을 inner로 바꿔야 한다고 제안하고 있습니까?

그것은 이미 내 생각에 큰 개선이 될 것입니다. 기능 및 구성 데이터에 대해 위에서 설명한 모든 예를 참조하십시오. 이 커뮤니티의 사람들은 작업에서 dot 라는 용어를 사용하지 않습니다. "점"은 다른 어떤 것보다 컴퓨터 과학 용어에 가깝습니다.

dot 의 이름을 $ inner $로 바꾸는 것은 dot 외에 inner 를 Base에 추가하는 것과는 상당히 다른 제안입니다. 그것은 "정확한 용어" 질문에 더 가깝습니다. 여러분과 다른 linalg 사람들이 해명해야 할 것입니다. 비록 우리가 이것을 한 번 자전거로 갈아타고 dot 가 이 함수가 구현하는 것에 대한 올바른 이름이라고 결론지은 것을 기억하는 것 같습니다.

https://github.com/JuliaLang/julia/issues/22227 및 https://github.com/JuliaLang/julia/pull/22220 에서 이에 대한 약간의 토론이 있었습니다.

점의 이름을 내부로 바꾸는 것은 점 외에 내부를 Base에 추가하는 것과는 상당히 다른 제안입니다.

이것이 이 스레드의 첫 번째 메시지에서 제안한 것입니다.

나는 점의 이름을 inner로 바꾸거나, 아마도 사용자에게 inner(x,y)를 객체 x와 y 사이의 일반적인 내부 곱으로 정의하도록 지시하고 싶습니다.

반복합니다. 내적은 여기서 논의하고 있는 작업에 대한 잘못된 용어입니다. 내부, 외부, 스칼라 곱... 이들은 수학적 개체입니다. "내적"은 계산 개체입니다. 두 개의 숫자 시퀀스를 가져오고 x1*y1 + x2*y2 + ... xn*yn , 다른 수학적 공간에서 쓸모없는 연산을 수행합니다.

나는 Base.dot 를 호출하기 위한 폴백과 함께 Base.inner 를 추가한 것으로 보이는 당신이 제안한 두 번째 옵션에 집중했습니다. 두 옵션 모두 가능하지만 둘 다 정당화해야 합니다. 새 작업을 추가하려면 패키지에 포함될 수 없는 이유가 필요합니다(이 토론의 초기 부분에 대한 내용). 이름을 바꾸려면 dot 가 잘못된 이름이고 inner 가 올바른 이름인지 결정해야 합니다(대화 내용이 무엇으로 바뀌었는지).

@juliohm 현재 Base 를 축소하고 패키지 사용을 장려하려는 적극적인 노력이 있음을 (재)말할 가치가 있습니다. 이 경우 dot 는 표준 Julia에서 제공되는 선형 대수학에 참여하는 모든 유형에 대해 올바른 것 같습니다 (예: Number 및 Array - 예, , 모든 경우에 유한 기반 - 따라서 더 나은 선택이 있을 수 있지만 용어에서 실수 를 저질렀다고 생각하지 않습니다. 저는 이 제안에 반대하지 않습니다. 그러나 변경에 대한 "잠재적" 저항을 경험할 수 있는 이유를 명확히 하기 위해 이것을 지적하고 싶었습니다.

또한 상당한 수의 Julia 신규 이민자가 내적에 익숙할 수 있지만 내적에는 익숙하지 않을 수 있다는 점(예: 대학에서 약간의 물리학을 했지만 수학 전공은 아님)을 염두에 두어야 할 몇 가지 이유도 있습니다. dot 를 유지하십시오(중위 연산자가 이에 해당한다는 것은 말할 것도 없고 - inner 에 매핑할 수도 있지만 이는 약간 덜 명확합니다). 우리는 또한 outer 함수나 다양한 다른 가능한 작업을 가지고 있지 않습니다.

따라서 이것을 Base (또는 LinAlg )에 넣는 것이 이것을 사용자 패키지에 넣는 것보다 엄격하게 더 나은 방법에 대한 합리적인 사례를 만들어야 하는 부담이 있습니다. 주된 이유는 다른 사람들이 공유하고 확장할 수 있는 인터페이스를 제공하는 것 같습니다 . 합리적인 요약입니까? Clustering.jl 의 일반 코드가 내부 제품과 함께 작동하도록 하는 것에 대한 주장은 꽤 설득력이 있어 보입니다. 또한 LinAlg 를 stdlib 패키지로 분할하는 것처럼 보이는 맥락에서 - LinearAlgebra 라는 패키지를 작성하면 inner 를 포함하게 되어 기쁩니다.

의견을 공유해 주신 @andyferris 에게 감사드립니다. 나는 저항을 매우 명확하게 보고 있는데, 이것은 내가 별로 흥분하지 않는 것입니다. 그럼에도 불구하고 이 특정 제안이 어떻게 코드 증가로 이어지는지 궁금합니다. 나에게는 추상화가 크게 개선된 코드의 사소한 변경처럼 보입니다. Clustering.jl의 예제는 많은 것 중 하나일 뿐입니다. 내부 제품의 개념이 존재하는 임의의 Julia 유형과 함께 작동하도록 만들 수 있는 모든 커널 기반 방법을 생각해 보십시오. MultivariateStats.jl에는 많은 것들이 있습니다.

LinAlg 를 별도의 패키지로 분할하는 것에 대한 의견에 대해서는 수학적 산출물을 캡슐화하기에 좋은 장소인 것 같다는 데 동의합니다. 이 미래의 LinearAlgebra 패키지는 기본적으로 Julia 세션에서 가져오기 때문에 모든 사용자가 inner , outer 등의 개념에 액세스할 수 있다고 가정합니다. 곧.

예, 표준 라이브러리는 모두 Julia 시스템 이미지와 함께 빌드되며 기본적으로 사용 가능합니다. 적어도 v1.x 시리즈의 경우 아무도 using LinAlg 를 입력할 필요 가 없습니다 LinearAlgbebra .

명확히 하자면 표준 Julia와 함께 로드되므로 아무것도 설치할 필요가 없지만 내보내는 이름을 얻으려면 using LinAlg 를 작성해야 합니다.

using LinAlg * 메서드 등을 얻을 것이기 때문에 이것이 이상해집니다. (즉, LinAlg 는 해적형입니다).

네, 기본적으로 여기에서 선을 그려야 합니다. Base는 LinAlg를 해적이 아닌 것으로 만드는 데 필요한 만큼 선형 대수 기능을 정의해야 하므로 Array 및 * 때문에 matmul이 Base에 정의됩니다.

구체적인 예를 들어 현재 인터페이스로 어떻게 해결할 수 있는지 물어보겠습니다. 아마도 이것이 저를 위해 명확하게 할 수 있을 것입니다.

목표는 구성 데이터로 요인 분석을 수행하는 것입니다. 나는 Composition 라는 타입과 작곡 공간에 내적을 가지고 있다. 나는 많은 샘플(예: 암석 샘플)을 수집하여 큰 Vector{Composition} 에 모두 넣습니다(예: 구성 = %water, %grain, %air). 이제 이 데이터 벡터에 대해 다른 패키지(예: MultivariateStats.jl)에 구현된 요인 분석 알고리즘을 호출하려고 합니다. 기본적으로 inner 제품을 가져오지 않고 일반적으로 어떻게 구현합니까?

마지막 의견에서 내가 이해한 것은 MultivariateStats.jl과 CoDa.jl이 모두 LinAlg.jl에 의존해야 한다는 것입니다. MultivariateStats.jl의 종속성은 inner 이름을 범위로 가져오는 것입니다. CoDa.jl의 종속성은 MultivariateStats.jl에서 호출할 수 있는 inner 에 대한 메서드를 정의하는 것입니다. 그것이 당신이 제안하는 것입니까?

Composition{D} 는 + 및 * 아래의 D 차원 벡터 공간인 것 같습니다.

나는 이중 벡터 공간을 정의하고 싶은 유혹을 받을 것입니다.

따라서 adjoint(::Composition) -> DualComposition 및 *(::DualComposition, ::Composition) -> scalar (현재 inner )를 정의할 수 있습니다. DualComposition 은 안에 Composition 를 들고 있는 것 외에는 많은 일을 할 필요가 없습니다.

https://en.wikipedia.org/wiki/Dot_product 의 첫 번째 문장은 dot 가 두 개의 iterable에 대한 작업이 될 수 있음을 시사 하는 것 같습니다. 이를 재귀적으로 만들고 Number 에 대해 정의하고 Number 와 AbstractArray 에 대해 겹치는 추상 선형 대수 함수로 inner 를 정의할 수 있습니다.

@andyferris 에게 감사합니다. 이중 공간에 대한 귀하의 생각에 감사드립니다. 하지만 이 작업에 대해 새로운 유형에 의존하지 않는 것이 좋습니다. 최종 솔루션은 불필요하게 복잡합니다.

내가 이해하는 데 관심이 있는 것은 다음과 같은 이유입니다.

inner(x,y) = sum(x.*y)
norm(x) = sqrt(inner(x,x))

export inner, norm

기지에 오신 것을 환영하지 않습니까? 이것이 전문화할 언어 사용자를 위해 일반적으로 함수 이름을 정의하는 데 필요한 전부라고 가정합니다. 핵심 개발자의 관점을 이해하려는 진정한 관심으로 이러한 질문을 하고 있음을 명심하십시오. 대화가 다시 엉뚱한 방향으로 흘러가기 전에 이 말을 하고 싶다.

일반적으로 수학에 관심이 있는 사람의 관점에서 이러한 개념을 기본적으로 내보내지 않고 대신 LinAlg 내부에 정의하는 것이 부자연스럽게 느껴집니다. 저는 LinAlg 를 배열 유형에 대한 이러한 고급 개념의 구현 이라고 생각합니다. 아마도 내 전체 작업은 배열에 대한 선형 대수학을 필요로 하지 않지만 패키지(예: MultivariateStats.jl, Clustering.jl) 전반에 걸친 내적 개념의 이점을 여전히 누릴 수 있습니다. 또한 LinAlg 를 내 패키지에 종속성으로 포함하고 싶지 않을 수 있습니다. 그렇지 않기 때문입니다.

더 강조하자면 배열과 무관한 내적 개념 이 있습니다. 이 개념은 Base의 export inner 문으로 표현됩니다. inner(x,y) = sum(x.*y) 좌표를 나타내는 배열과 유사한 객체에 대한 내부 제품의 구현 이 있습니다. 이 작업은 필요에 따라 위와 같이 Base에서 fallback 방식으로 정의할 수 있습니다.

사용 사례의 또 다른 예는 Krylov 방법입니다. 예를 들어 내부 곱이 있는 함수 공간이 있는 경우 Krylov 방법을 사용하여 해당 무한 차원 함수 공간의 작은 유한 차원 부분 공간에서 선형 문제 또는 고유 문제를 근사화할 수 있습니다.

나도 벡터/힐베르트 공간을 형성하지만 <: AbstractArray 의 일부가 아닌 나만의 객체를 가지고 있습니다. 순위가 N>1 인 배열도 벡터 공간을 형성하고 Krylov 방법에서 '벡터'로 사용할 수 있는 비유에서 vecdot 및 vecnorm 사용에 의존하게 되었습니다. 내적과 규범의 일반화된 개념이다. 그래서 저는 함수를 선형 연산자로 사용하는 Krylov 메서드를 사용하여 패키지를 개발해 왔습니다. 여기서 '벡터'는 모든 유형이 될 수 있습니다. 단, 해당 유형의 객체는 vecdot , vecnorm 및 몇 가지를 지원합니다. 다른 것들( scale! , zero , ...). 그러나 Base에서 이러한 개념이 의미하는 바를 남용하는 것일 수 있으므로 여기에서 올바른 인터페이스를 바로잡는 것이 좋습니다.

오른쪽 - vecdot 의 이름을 inner 로 바꿀 수 있습니다.

(이제 norm 가 항상 inner 와 일치하는 행렬에 대해 norm 를 실제로 matrixnorm 라고 불러야 하는지 막연히 궁금합니다. norm 에서 진행되는 상황은 일반화하는 데 약간의 어려움을 일으키고 있음)

사실, 일반적인 벡터와 같은 객체의 경우 벡터 공간의 차원을 쿼리하는 것도 유용합니다(예: Krylov 차원이 내 예제 사용 사례에서 전체 공간의 차원보다 크지 않아야 함을 확인하기 위해). 중첩 배열의 예는 여기서 length 가 올바른 개념이 아님을 보여줍니다. 즉, 이러한 경우에 길이에 대한 재귀적 개념이 필요합니다.

이제 중첩 배열을 일반 벡터로 사용하는 예의 경우 vecdot 및 vecnorm 는 #25093에서 논의된 바와 같이 어떤 경우에는 내적 및 규범의 올바른 개념도 아닙니다. 즉, vecdot 및 vecnorm 를 재귀적으로 호출하지 않습니다. 일반적인 내부 제품 및 표준 기능으로 이러한 기능에 대한 나의 해석은 #25093을 촉발한 것입니다. 그러나 이것이 이러한 기능이 의도된 방식과 다를 수 있는 것 같습니다(대신 수행하려는 의도가 확실하지 않음).

따라서 패키지 전반에 걸쳐 사용할 수 있는 일관된 인터페이스가 필요하다는 데 동의합니다. 따라서 중앙 위치에 속할 것입니다(아마도 Base에는 없지만 확실히 표준 라이브러리에 있어야 합니다. 예를 들어 using VectorSpaces ). 이름 지정과 관련하여 두 가지 옵션이 표시됩니다.

옵션 1(지금까지 내 해석):
접두사 vec 는 객체를 일반 벡터로 해석할 때 해당 객체의 속성을 나타내므로

• 중첩 배열의 vecdot 및 vecnorm 가 수정되었습니다(PR #25093).
• 새로운 veclength 정의가 추가되었습니다.

옵션 2(아마도 더 나음): 수학적으로 더 정확한 이름을 사용합니다.

• inner
• dimension
• 하지만 norm 로 무엇을 할까요?

마지막으로 @stevengj 에게 핑을 치면 확실히 유용한 의견이 있을 것입니다. 불편하시다면 죄송합니다.

이름은 이 모든 것 중에서 가장 흥미로운 부분입니다. 임의의 힐베르트 공간에 대한 일반 내적을 참조하기 위해 dot 함수를 사용하는 데 아무런 문제가 없습니다. 예를 들어 "두 함수의 내적"에 대한 다른 합리적인 의미가 없을 뿐만 아니라, 특히 유한 차원 벡터에 대한 유추를 강조하려는 교육적 설정에서 비공식적인 사용에서 "함수의 내적"을 보는 것이 매우 일반적입니다. 공백.

@juliohm , inner(x,y) = sum(x.*y) 는 일반적으로 내부 제품도 아니므로 기본에 넣는 것은 꽤 끔찍한 대안이 될 것입니다.

그러나 dot 는 이미 벡터로 동작하는 Base의 다양한 객체에 대한 올바른 내적을 계산하지 않고 있습니다(사실 실패) N>1 제대로 작동하는 곳). 게다가, 일반 이름 norm 는 행렬에 대해 모호해집니다. 왜냐하면 이것이 유도된 노름을 반환하도록 하는 현재 선택에 동의하지만 때때로 "벡터 노름"(Frobenius 노름)도 필요하기 때문입니다.

따라서, 내 영향이 가장 적은 제안은 vecnorm(x) = norm(vec(x)) 의미론을 버리고 vecnorm(x) 를 " x 이 벡터 공간에서 x "( vecdot 와 유사)의 해당 벡터 노름을 계산합니다. 이것은 해석(따라서 문서화)의 이동이지만 Base의 개체에 대한 실제 구현/작업은 크게 다르지 않으며(PR #25093) 대부분의 경우 동일한 결과를 생성합니다(순위 N 배열 스칼라 또는 벡터). $#$10 x #$의 해당 벡터 공간 차원을 반환하는 함수 veclength(x) 는 인터페이스를 완성합니다.

그런 다음 사용자 정의 패키지는 벡터로 작동하는 새 유형을 정의할 때 이러한 기능을 구현하는 방법을 배워야 합니다.

비공식 사용에서 "함수의 내적"을 보는 것은 매우 일반적입니다. 특히 유한 차원 벡터 공간에 대한 비유를 강조하려는 교육학 설정에서

이름이 중요하지 않다고 말하지 마십시오. 나는 n번째 반복할 것이다: 내적과 내적은 같은 것이 아니다. 추상 Hilbert 공간으로 작업을 노출하는 심각한 재료는 "점"을 사용하지 않습니다. 내 말보다 Wikipedia를 신뢰하는 것을 선호한다면 여기에 정의를 복사하여 붙여넣었습니다.

내부 제품

선형 대수학에서 내적 공간은 내적이라는 추가 구조 를 가진 벡터 공간입니다. 이 추가 구조 는 공간의 각 벡터 쌍을 벡터의 내적이라고 하는 스칼라 수량과 연결 합니다.

내적

수학에서 내적 또는 스칼라 곱은 두 개의 동일한 길이 의 숫자 시퀀스 (일반적으로 좌표 벡터)를 취해 단일 숫자를 반환하는 대수 연산 입니다.

언어의 용어와 수학적 일관성을 개선하려는 이러한 저항은 의욕을 꺾습니다. 내가 당신에게 아무리 많은 사실을 제시해도, 사례와 사용 사례의 수에 상관없이, "나는 점이 좋다"라는 말 외에는 반론이 없다.

@juliohm , 용어는 정확성이 아니라 관례의 문제입니다. 나는 Hilbert 공간, 특히 무한 차원 공간에 대한 공식적인 사용에서 "내적"이라는 용어가 거의 독점적으로 사용된다는 데 동의합니다. 그러나 내가 말했듯이 "내적 함수"를 Google에 검색하면 해당 용어의 비공식적인 사용법도 많이 찾을 수 있습니다. "이 힐베르트 공간의 두 요소의 내적을 취하십시오"라고 말하면 모든 수학자는 무한 차원 공간의 경우에도 내적을 참조한다는 것을 알게 될 것이므로 혼동의 실제 위험은 없습니다. "내적"이라는 용어의 표준 일반화. 이것이 내가 "점" 대 "내부"의 철자 논쟁을 중심 문제로 보지 않는 이유입니다.

여기서 원하는 의미 체계와 유형이 새로운 Hilbert 공간 또는 Banach 공간을 정의하는 경우 구현해야 하는 함수 집합을 결정하는 것이 중요합니다. 현재 새로운 Hilbert 공간을 나타내는 유형을 정의하려면 dot 및 norm adjoint 정의해야 합니다(현재 후자에 대한 대체가 없기 때문에). 이중 공간 개체에 대한 매핑을 원하는 경우

@Jutho 가 말했듯이 배열 배열의 경우에는 모든 것이 복잡합니다. 원하는 것이 여러 개 있기 때문입니다. 가능한 모든 의미론에 대해 표준화된 이름이 없기 때문에 모든 사람을 만족시킬 이름/의미론을 찾기가 어렵습니다. vecdot 의미론에 대한 논의는 #25093을 참조하십시오. 나 자신도 여기에 좋은 대답이 없습니다.

여기에 몇 가지 가능성

1. x[i]' * y[i] 의 합계 . 현재 dot(x,y) 입니다. 행렬 벡터에 대한 내적(행렬을 제공하는 경우)이 아니며 현재 다차원 배열에 대해 모두 정의되어 있지 않습니다.
2. dot(x[i], y[i]) 의 합계(다차원 배열 포함) 및 conj(x)*y 8$#$ 의 경우 Number . 현재 vecdot(x,y) 입니다.
3. inner(x,y) 와 같은 일부 함수는 항상 진정한 내부 곱으로 정의되고 배열의 경우 합계 inner(x[i],y[i]) — 본질적으로 @Jutho 가 원하는 "재귀적 vecdot"입니다. 그러나 A 행렬의 경우 이 내적은 현재 norm 정의인 유도된 규범 norm(A) 과 일치하지 않습니다. 이 문제를 해결하려면 행렬이 Frobenius 표준으로 기본 설정되도록 norm(A) 를 변경해야 하며, 이는 잠재적으로 광범위한 주요 변경 사항이 될 수 있습니다.

질문(#25093에서 부분적으로 논의됨)은 Base에서 이 세 가지 모두가 필요한지, 아니면 두 개만 가지고 벗어날 수 있는지(그리고 무엇을 두 개, 그리고 무엇이라고 부릅니까)입니다. @Jutho 의 제안은 기본적으로 Base에서 옵션 2를 제거한 다음 옵션 3에 대해 vecdot 및 vecnorm 를 사용하는 것입니다. 그러면 진정한 내부 제품이 있지만 용어는 Julia에게는 다소 고유하고 무한 차원 Hilbert 공간과 같이 약간 이상합니다. 물론 그것이 세상의 끝은 아닐 것입니다.

또 다른 가능성(우리가 vecdot 로 하는 것과 약간 독립적)은 dot 가 진정한 내부 제품이 되도록 요구하는 것으로 (뒤로) 돌아가는 것입니다. 즉, 행동 1을 제거하고 dot(x::AbstractVector, y::AbstractVector) 를 sum dot(x[i],y[i]) 와 동일하게 만듭니다. 여전히 다차원 배열에 대해 정의하지 마십시오( norm 와 일관성을 유지하기 위해).

나의 현재 개인적인 성향은 dot 를 진정한 내적( norm 와 일치해야 함)으로 정의하여 벡터에 대해 dot(x[i],y[i]) 의 합계로 변경하는 것입니다(즉, 행렬 벡터의 경우), 다차원 배열에 대해서는 계속 정의하지 않습니다. 그런 다음 vecdot 를 정의하여 @Jutho 가 제안한 대로 vecdot(x,y) = dot(x,y) 대체 $ vecdot $ 를 재귀적으로 호출합니다. 마지막으로, 새로운 "Hilbert-space" 유형은 dot 및 norm 를 정의해야 한다고 말합니다. 이것은 나에게 가장 방해가 적고 이해하기 쉬운 변화처럼 보입니다.

( norm(x) = sqrt(real(dot(x,x))) 폴백도 가능하지만 스퓨리어스 오버플로에 취약하기 때문에 다소 위험합니다. 기술적인 이유로 sqrt(dot(x,x)) 를 폴백으로 사용할 수 없습니다. Real 결과가 아니라 Complex 결과입니다.)

이 유익한 반응에 대해 @stevengj 에게 감사드립니다. 하나의 작은 의견:

대체 vecdot(x,y) = dot(x,y) . 마지막으로, 새로운 "Hilbert-space" 유형은 dot 및 norm 를 정의해야 한다고 말합니다.

거기에는 두 가지 문제가 있습니다. $# vecdot 는 일반 반복자를 처리하기 위해 이미 Any 인수를 허용하므로 $ vecdot(x,y) = dot(x,y) fallback은 존재할 수 없습니다. 두 번째 문제는 dot 및 norm 가 사용자 유형과 같은 벡터가 정의해야 하는 진정한 내적 및 규범으로 노출되면 Krylov 메서드와 같은 패키지를 작성할 때에도 유형과 같은 완전히 일반적인 벡터와 함께 작동해야 하지만 사용자가 객체와 같은 벡터로 중첩 또는 다차원 배열을 사용하려는 경우에는 여전히 작동하지 않습니다. 따라서 vecdot 및 vecnorm 는 벡터와 같은 객체의 일반적인 내적 및 규범이라고 주장합니다. 이것은 또한 행렬의 경우 대부분의 사람들이 실제로 norm 가 유도된 행렬/연산자 표준이 될 것으로 기대한다는 사실과도 잘 맞습니다.

실제 사용 사례의 경우(이것이 예외적인 경우가 아님을 보여주기 위해). 확률적 행렬은 해당 고유 벡터가 고정 소수점 확률 분포를 나타내는 가장 큰 고유값(Perron-Frobenius)을 가집니다. 그 양자 일반화에서 확률 분포는 양의 정부호 행렬(밀도 행렬)로 일반화되며 이러한 행렬은 완전히 양의 맵, 즉 맵 rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) 의 고정점(최대 고유값에 해당하는 고유 벡터)입니다. 여기서 rho 는 밀도 행렬이고 A[i] 는 모든 i 에 대한 행렬입니다(완전히 양의 맵을 나타내는 Kraus 연산자로 알려짐). 큰 행렬 차원의 경우 Arnoldi 방법은 고정 소수점 밀도 행렬을 찾는 데 이상적으로 적합합니다.

나의 현재 개인적인 성향은 점을 진정한 내적(규범과 일치해야 함)으로 정의하여 벡터에 대한 점(x[i],y[i])의 합으로 변경하는 것입니다. 마지막으로, 새로운 "Hilbert-space" 유형은 점과 규범을 정의해야 한다고 말합니다.

그것은 이미 엄청난 발전입니다. Base에서 inner dot 를 문서화하면 최소한 사용자가 불필요한 라이브러리를 가져오지 않고 자신의 공간을 정의할 수 있습니다. 이름이 마음에 들지는 않지만 최소한 필요한 사람들은 기능을 사용할 수 있을 것입니다.

예, "Hilbert-space" 유형에 대해 구현하기 위해 문서화된 인터페이스를 갖는 것이 좋을 것이라고 생각합니다.

물론, 벡터 공간에 대한 이 일반 인터페이스 에 대해 생각하면 위에서 제안한 대로 norm 가 포함되어 있으면 행렬에 대한 Frobenius 표준 이어야 합니다(모든 배열이 벡터의 요소이기 때문에 고차원 배열에 대해 일반화해야 합니다. 공간). 이 경우 행렬에 대한 별도의 "연산자 기준" 함수가 필요합니다( matnorm 또는 opnorm 또는 norm 에 대한 키워드 인수 ...).

@andyferris , 내 마지막 의견을 적어주세요. norm 및 dot 는 고차원 배열 및 중첩 배열과 같은 Julia의 객체와 같은 벡터에서도 작동하지 않기 때문에 일반 Hilbert 공간 인터페이스가 될 수 없습니다. 따라서 vecdot 및 vecnorm 는 이에 대한 '더 나은'(최소 파괴의 의미에서) 후보입니다.

가까운 장래에 언어로 수행할 것으로 예상되는 수학 유형과 상당히 관련이 있다고 생각하는 이 주제를 되살리십시오. 내부 제품의 일반성과 의미를 개선하기 위해 무엇을 할 것인지에 대한 합의가 있습니까?

다음은 제품에 관한 내 개인 수학 온톨로지의 일부입니다.
기억을 정리하는 데 도움이 된다면 / 합의를 이끌어내는 데 도움이 될 수 있다면

• 내적 ; 동의어 : 스칼라 곱
• 내부 제품
• 외적
• 텐서 곱 ; 동의어 : 외부 제품
• 웨지 제품 ; 동의어 : 외장 제품
• 컵 제품
• 트리플 제품

보너스: 위키피디아 참조 없음

이 시점에서 #25093에 있는 @Jutho 의 제안은 vec* 용어가 이 맥락에서 나에게 약간 이상하더라도 가장 방해가 되지 않는 변경으로 보입니다.

vec* 용어가 이상하다는 데 동의합니다. 이것이 표준 이름을 갖도록 함수 이름을 바꾸는 것이 모든 사용자에게 유익한 이유입니다.

나도 마찬가지로 vec* 용어가 이상하다는 데 동의합니다.

vecdot 에 대한 대안으로 새로운 방법 inner 을 도입할 수 있지만 vecnorm "대체"할 좋은 이름을 모르겠습니다. 사실, 나는 vecnorm 가 나쁘다고 생각하지 않습니다. 벡터 규범은 우리가 원하는 작업에 대해 잘 확립되고 명시적인 용어입니다.

여기서 기본적인 문제는 행렬 및 다차원 배열에 관한 것입니다. 일반적인 norm(A) 는 내적에 해당하지 않으며 위에서 논의한 배열의 배열에도 해당하지 않습니다. 어떤 내부 제품이 의도된 것인지 나타내기 위해 이러한 경우에 약간의 명확성(예: vec* 또는 fro* )이 필요합니다.

기본값이 vecdot 인 inner 함수를 가질 수 있지만 동일한 함수에 대해 두 개의 이름을 갖는 것은 약간 어리석고 표준을 무엇이라고 부를지 여전히 문제가 있습니다.

나는 또한 vecdot 이름이 이상하다는 것을 알았습니다. 사실, 나는 그것이 존재하는지조차 몰랐고 inner 라는 자체 기능을 만들었습니다.

내 이해는 우리가 inner vecdot 을 더 이상 사용하지 않고 사용자가 자신의 공간을 구현할 수 있도록 내부 제품 의미를 부여할 수 있다는 것입니다.

norm 에 대해서는 잘 모르겠습니다. 내부 제품에 대해 논의하기 위해 이 문제를 열었습니다. Base의 규범 상태를 논의하는 데 또 다른 문제가 적절할 수 있습니다.

vecdot 및 vecnorm 대신 inner(x,y) 및 innernorm(x) = sqrt(inner(x,x)) (오버플로를 방지하기 위해 최적화된 특수 사례 포함)가 있을 수 있다고 가정합니다. innernorm 는 약간 특이하지만 문맥상 상당히 명확합니다.

이 변경 사항에 대해 엄지손가락을 치켜듭니다. inner 및 innernorm 이름은 명확하고 개념과 일치합니다. Julia v1.0으로 만들 수 있기를 바랍니다.

inner 및 innernorm 는 괜찮은 것 같습니다.

내 생각에 우리의 norm 함수는 Julia의 일반 함수 및 디스패치 시스템과 디스패치가 없어야 하는 "명확한 인터페이스"라고 부르는 것과 정말 잘 맞지 않습니다. 의미론적 선택, 단지 구현 선택. 저는 개인적으로 " norm 는 벡터 공간 요소의 노름을 반환합니다"라고 말할 수 있습니다. 여기서 행렬과 선형 연산자는 여전히 벡터 공간의 요소입니다(이를 더하고 스칼라로 곱할 수 있음) . 예를 들어 " opnorm 는 선형 연산자의 연산자 노름을 반환합니다"(또는 matnorm 또는 무엇이든 간에)를 가질 수도 있습니다.

현재 우리는 " norm 는 벡터 공간의 요소의 노름을 반환합니다. 단, 요소 가 선형 연산자인 경우에는 대신 연산자 노름을 줄 것입니다." 나는 개인적으로 파견이 놀랍지 않아야 한다고 생각합니다.

즉, 나는 항상 벡터 노름을 수행하는 하나의 함수와 항상 연산자 노름을 수행하는 다른 함수를 선호하고 둘 다 수행하려고 하는 함수는 선호하지 않습니다 .

@andyferris :+1: 공간의 내적에 의해 유도된 규범이 아닌 특정 규범은 더 구체적인 이름을 가질 수 있습니다. norm 이름은 정확히 norm(x) = sqrt(inner(x,x)) 를 의미하며 사용자 유형에 따라 필요에 따라 재정의할 수 있습니다.

저는 개인적으로 " norm 는 벡터 공간 요소의 표준을 반환합니다"라고 말할 수 있습니다.

현재 norm 함수는 해당 정의를 충족합니다. 행렬 의 경우 벡터 공간에 대해 완벽하게 유효한 노름 인 유도(연산자) 노름을 계산합니다. (벡터 공간에는 내적이나 규범이 전혀 필요 하지 않습니다.)

연산자 노름이 "벡터 공간의 노름"이 아니라고 생각한다면 "규범"의 정의에 대해 다소 혼란스러울 수 있습니다.

이것은 norm 와 innernorm 사이의 유용한 구별이기도 합니다. norm 를 정의하면 Banach 공간(또는 최소한 표준 벡터 공간)이 있다는 것만 의미한다고 말할 수 있습니다. innernorm 를 정의하면 Hilbert 공간(또는 최소한 내부 곱 공간)이 있고 이 규범이 inner 와 일치함을 의미합니다.

예를 들어, 적응적 수치 적분(ala quadgk)은 내적 공간이 아닌 표준 벡터 공간만 필요한 것입니다.

물론 죄송합니다. 제 언어가 너무 정확하지 않았을 수도 있습니다. 다양한 연산자 규범을 포함하여 벡터 공간에 대해 유효한 많은 규범이 분명히 있습니다.

내 생각에 내가 얻고 있는 것은 아마도 내가 암시적인 것보다 더 명시적인 규범을 선택 하는 것을 선호한다는 것입니다. 그리고 동일한 기능을 사용하면(예: 추가 키워드 인수 없이) "동일한" 표준을 얻게 되며, 이 경우 유클리드가 AbstractArray 에 대해 다소 방어 가능한 선택처럼 보입니다.

이것은 norm 와 innernorm 사이의 유용한 구별이기도 합니다. 노름을 정의하면 바나흐 공간(또는 적어도 노름 벡터 공간)이 있다는 것만 의미한다고 말할 수 있습니다. innernorm 를 정의하면 Hilbert 공간(또는 최소한 내부 곱 공간)이 있고 이 규범이 inner 와 일치함을 의미합니다.

이것은 합리적으로 보이지만 개체에 innernorm 가 있는 경우 다른 norm 가 필요한 이유 가 궁금합니다. 또는 Banach 공간에 대한 인터페이스 에는 norm 가 필요하고 내부 제품 공간에 대한 인터페이스는 norm 및 inner 모두를 제공한다고 제안합니다. 그런 다음 이러한 함수는 Banach 또는 내부 제품 공간의 개체를 적절하게 기대하는 일반 코드에서 사용할 수 있습니다(편집: Banach 공간에서 작동하는 코드가 자동으로 내부 제품 공간에서도 작동할 것이라는 생각으로).

나는 norm(x) 가 항상 어떤 종류의 요소별 유클리드 규범(즉, 행렬에 대한 Frobenius 규범)을 참조한다고 제안하고 있다고 생각합니다. 즉, 기본적으로 vecnorm 가 이제 모듈로 재귀 사례입니다. 이 경우 dot(x,y) 를 해당 내부 제품으로 재정의할 수도 있습니다( inner 도 작동하지만 dot 에는 중위 변형 x ⋅ y 의 이점이 있습니다. ).

원칙적으로는 괜찮지만 이는 획기적인 변경 사항이 될 것이며 0.7 이전에는 약간 늦을 수 있습니다.

L2는 고차원에서도 좋은 기본값입니까?
이 기사에서는 거리에 대해 이야기하지만 규범과도 관련이 있을 수 있습니다.
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

이 경우 우리는 dot(x,y)를 상응하는 내적(inner product)으로 재정의할 수도 있습니다.

dot 완전히 없앨 수 있습니까? 중위 표기법은 dot 라는 함수의 존재와 관련이 없어야 합니다. Julia 배열에 대해 inner 메서드로 중위를 정의하기만 하면 됩니다. 그게 가능합니까?

이것이 바로 내적입니다. 유클리드 기하학을 사용하여 R^n에서 x와 y 벡터 사이의 내적에 대한 편리한 표기법 x ⋅ y입니다.

@stevengj 좋은 요약이라고 생각합니다. 네.

@ o314 L2는 고차원에서 좋은 기본값입니까? 아마도 그렇지 않을 수도 있지만 예를 들어 norm(v::AbstractVector) 에 의해 선택된 표준이 $# length(v) #$에 의존한다면 나는 그것을 정말로 싫어할 것입니다 :) 나는 똑같이 내 행렬이나 고차원 배열을 추측하는 것을 좋아하지 않을 것입니다. is "too big for L2" - 아마도 이것은 사용자가 명시적으로 표시해야 한다고 제안하고 싶습니다.

@juliohm 분명히 가능하지만, 언급한 것처럼 이는 우리가 제안하는 주요 변경 사항입니다. (다시, 재귀 사례에서 무엇을 할 것인지와 inner 와 dot 사이의 가능한 차이점에 대한 이전 논의를 모듈화합니다.)

@stevengj , @andyferris 가 의미하는 바에 대한 내 해석은 오리 타이핑 때문에 사용자가 객체를 벡터로 해석하고 해당 벡터 p -norm을 사용하기를 원하는지 여부를 결정하기 어렵다는 것입니다. 또는 연산자로 (그리고 유도된 p -norm을 계산). 따라서 원하는 동작을 명시적으로 지정하는 것 외에는 선택의 여지가 없다고 생각합니다. 현재 접근 방식은 norm 가 입력을 기반으로 벡터 노름 또는 유도 노름을 선택할지 여부를 암시적으로 추측하려고 시도하고 vecnorm 가 원하는 것을 명시적으로 지정하는 방법이라는 점에서 약간 이상합니다. 벡터 규범(이것이 내가 vecnorm 같은 나쁜 이름을 찾지 못하는 이유이기도 합니다). 보다 근본적인 변경은 norm 를 항상 벡터 노름으로 기본 설정하고 (키워드) 인수 또는 다른 기능을 함께 사용하여 유도된 노름을 원할 때 명시적으로 지정하는 것입니다.

다른 한편으로, 나는 이것이 내적 기반 규범이라는 점에서 명시적인 innernorm 이름도 신경 쓰지 않습니다(즉, 유클리드의 경우 항상 p=2 ). 일부 사용 사례에서는 p=2 만 쉽기 때문에 사용자 정의 개체 (vec)norm 가 인터페이스의 일부로 선택적 인수 p 를 지원해야 하는지 여부를 판단하기가 어렵습니다. 계산하기.

이것이 바로 내적입니다. 유클리드 기하학을 사용하여 R^n에서 x와 y 벡터 사이의 내적에 대한 편리한 표기법 x ⋅ y입니다.

일반(예: 복잡한) 벡터 공간의 맥락에서 x ⋅ y 표기법을 본 기억이 없다는 점에서 이에 동의합니다. 이런 경우에는 수학적 표기법 (x,y) 또는 Dirac 표기법 < x | y > 만 사용한다고 생각합니다. 전자기학에서는 종종 3차원 유클리드 공간의 벡터에 E ⋅ B 를 사용하며, 복잡한 표기법(즉, 페이저)을 사용하더라도 이것이 복잡한 켤레를 의미하지는 않습니다. 필요한 경우 이러한 경우 복합 활용이 명시적으로 표시됩니다. 따라서 dot 가 복소수 또는 에르미트 켤레 없이 sum(x_i * y_i) 가 되고 inner 가 일반 내부 제품 공간에 대한 올바른 내부 제품이 되더라도 상관하지 않을 것입니다. 불행히도 이것은 단일 릴리스 주기에서 수행될 수 없습니다.

L2는 고차원에서 좋은 기본값입니까? 아마도 아닐 수도 있지만, 예를 들어 norm(v::AbstractVector) 에 의해 선택된 표준이 length(v) 에 의존한다면 저는 정말로 그것을 싫어할 것입니다. :) 제 행렬 또는 고차원 배열이 "L2에 비해 너무 큼" - 사용자가 명시적으로 표시해야 합니까?

저는 2d 및 3d를 처리하는 BIM 세계에서 일하지만 4d, 5d, 6d도 7d일 수 있습니다. 우리는 더 이상 가지 않습니다. 어느 시점에서 우리는 어떤 차원에서 일하고 어떤 알고리즘이 관련되어 있는지 압니다. 그것으로 충분합니다.

ML, 정보 검색 등에서 일하는 사람들의 관점을 표현할 수 없습니다. 거기에는 norminf가 더 좋을 수 있습니다. 내 관점에서 중요한 것은 추측 가능성과 안정성입니다. ML의 사람들이 자신의 물건에 대해 다른 기본값을 필요로 하는 경우 전혀 충격을 받지 않을 것입니다. 혼란이 없다면. 예. 컴파일 타임에 명시적이고 정적으로 결정됩니다. Algos 적용 중에 안정적이고 일관성이 유지된다면 사치입니다.

array:similar 에서 영감을 얻었 습니다. 완전히 구현되지 않고 테스트합니다.

norm2 = x -> x |> inner |> sqrt
norminf = ...
NMAX = 10
for N in 1:NMAX
    <strong i="13">@eval</strong> begin norm(a::Array{T,N}) where {T} = norm2 end
end
norm(a::Array{T,n}) where {T} = norminf

점을 완전히 없앨 수 있습니까? 중위 표기법은 점이라는 함수의 존재와 관련이 없어야 합니다. Julia 배열에 대한 내부 메서드로 중위를 정의하기만 하면 됩니다. 그게 가능합니까?

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L498
vecdot(x::Number, y::Number) = conj(x) * y # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L657
dot(x::Number, y::Number) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L659
function dot(x::AbstractVector, y::AbstractVector) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L677

# Call optimized BLAS methods for vectors of numbers
dot(x::AbstractVector{<:Number}, y::AbstractVector{<:Number}) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L698

Dot / vecdot는 켤레를 사용하고 BLAS로 갈 시기를 결정하는 것을 의미합니다. 이것은 어딘가에서 처리해야합니다. 그러나 이것은 단일 네임스페이스에서 관리할 수 있어야 합니다.

L2는 고차원에서 좋은 기본값입니까? 아마도 아닐 것이다

L2는 또한 무한 차원 공간(예: 함수)에 대한 가장 일반적인 표준입니다. 모든 벡터 공간에 대해 기대하는 것이 합리적인 기본값이라고 생각합니다.

분명히 다른 규범도 사용할 수 있기를 원합니다. norm(x) 를 가능한 한 요소별 L2로 재정의하면 norm(x, p) opnorm 요소별 Lₚ이 되며 해당 유도/ 운영자 규범.

일반(예: 복잡한) 벡터 공간의 맥락에서 x ⋅ y 표기법을 본 적이 없다는 점에서 이에 동의합니다.

다른 스레드 IIRC에서 여러 인용을 했습니다(예: BLAS는 복잡한 내적에 대해 dot 를 사용하고 함수의 내적이라는 용어를 사용해도 교육학적 소스를 찾을 수 있습니다). "내적"이라는 용어는 일반적으로 "내적의 일반화"로 소개됩니다. 유클리드 내적에 대한 dot 표기법에 놀라지 않을 사람이 없을 것입니다. 중위 연산자가 있으면 편리합니다.

물론 dot 를 그대로 유지하고 $# inner 를 도입할 수도 있지만 그렇게 하면 혼란스러운 이분법이 생길 수 있다고 생각합니다. 가장 일반적인 경우에는 기능이 동일하지만 이상한 경우에는 (예: 행렬 배열) 그들은 다를 것입니다.

그러나 다시 변경 사항을 깨기에는 조금 늦을 수 있으므로 innernorm 및 inner 에 의존해야 할 수도 있습니다. 어쨌든 누군가는 최대한 빨리 PR을 작성해야 합니다.

합의에 대한 합당한 척도가 형성되면 잠재적인 주요 변경 사항이 포함된 관련(짧은) 기간에 구현을 탐색하는 데 약간의 대역폭을 할애할 수 있습니다. 이러한 작업의 의미를 명확히 하고 명확한 이름을 지정하려는 노력에 감사드립니다. 최상의!

두 가지 주요 옵션이 표시됩니다.

• 중단되지 않고 inner(x,y) 및 innernorm(x) 기능을 추가합니다. vecdot 및 vecnorm 대체 및 배열 배열의 경우 재귀적입니다.

• 중단: norm(x,p=2) vecnorm 를 대체하여 항상 요소별 및 재귀적으로 norm(x,p=2) 를 변경하고 연산자/유도 표준에 대한 새 함수 opnorm 도입. dot(x,y) 를 vecdot 로 대체하여 해당하는 요소별 내적을 만듭니다. (대안: 이름을 inner 로 변경하지만 중위 연산자가 있는 것이 좋으며 dot 와 inner 가 모두 있는 것은 성가신 일입니다.)

처음부터 디자인한다면 2를 선호하지만 norm 의 의미를 조용히 변경하기에는 너무 방해가 될 수 있습니다.

한 가지 중간 옵션은 inner 및 innernorm ( vecdot 및 vecnorm 사용 중단)를 정의하고 norm(matrix) 를 opnorm 로 사용하지 않는 것입니다. norm(matrix) = innernorm(matrix) 를 다시 도입합니다. 그렇게 하면 사람들은 결국 inner 및 norm 를 사용할 수 있고 dot 를 배열 벡터에 대한 현재 이상한 짐승으로 남길 수 있습니다( inner 는 숫자 벡터의 경우).

innernorm 에 대한 한 가지 이상한 점은 L1 또는 Linf "요소별" 규범을 지정하는 방법을 원하지만 이들 중 어느 것도 내부 제품에 해당하지 않으므로 innernorm(x,p) 는 약간 잘못된 이름입니다.

나는 당신의 중간 옵션을 좋아합니다.

위에서 언급했듯이 p=2 를 의미하고 두 번째 인수가 없어야 하기 때문에 innernorm(x) 라는 이름을 좋아합니다. 내적 규범을 계산하는 방법만 알고 있는 대상이 있습니다. 그러나 현재 (vec)norm 에서는 p 인수가 가정된 Base 인터페이스의 일부인지 여부가 명확하지 않으므로 두 번째 인수를 생략할지 아니면 지원해야 할지 모르겠습니다. 하지만 명시적으로 p != 2 를 확인하고 오류를 생성합니다.

그러나 제안의 중간 단계에서 vecnorm(matrix, p!=2) 를 사용하지 않는 데 사용되지 않는 문제가 있습니다.

나는 또한 중간 옵션을 좋아합니다. 우리는 즉각적인 주요 변경을 하기보다는 규범에 대한 적절한 사용 중단 주기를 확실히 거치기를 원합니다. (사용자로서 주요 변경 사항이 두렵지만 v1.0용 코드에서 사용 중단을 수정하는 것은 미래를 위한 깨끗하고 명확한 코드에 대한 투자와 같습니다.)

실제로 innernorm 가 필요합니까 아니면 지금은 $# vecnorm vecnorm norm 사용할 수 있습니까?

나는 실제로 dot 를 inner 로 대체하는 데 잠재적 소란이 없다고 생각합니다. 내적도 내적의 일반화를 의미한다는 것이 충분히 분명하다고 생각합니다.

변경 사항은 두 개의 개별 PR에서 구현할 수 있습니다.

1. dot 를 inner 로 바꾸고 일반화된 의미를 부여합니다. 선택적으로 중위 \cdot 표기법이 Julia 배열 사이의 내부를 가리키도록 합니다.
2. 표준 변형 및 용어에 대한 추가 토론 및 사용 중단 주기.

내 이해는 PR 1이 Julia v1.0 이전에 병합될 수 있다는 것입니다. 깨지지 않습니다.

dot 를 inner 로 바꾸는 것은 여전히 ​​깨질 것입니다. 왜냐하면 dot 는 현재 배열 배열에 대한 진정한 내부 곱이 아니기 때문입니다. 따라서 이름을 바꾸는 것이 아니라 의미를 바꾸는 것입니다. 나는 그 의미를 진정한 내적(inner product)으로 바꾸기 위한 것이지만, 의미를 바꾸면(진정한 내적이라고 정의) 그것을 dot 로 계속 철자하는 데 문제가 있다고 보지 않습니다.

따라서 0.7에서 다음을 수행할 수 있습니다.

1. norm(matrix) 는 opnorm(matrix) 로, norm(vector of vectors) 는 vecnorm 로 지원 중단됩니다.
2. $#$ sum dot([vector of arrays], [vector of arrays]) 를 더 이상 사용하지 않습니다.
3. vecdot(x,y) 및 vecnorm(x, p=2) 가 유클리드 내부 곱/규범( p=2 )이고 재귀적으로 만듭니다(약간 깨질 수 있지만 실제로는 큰 문제가 아닐 수 있음). .

그런 다음 1.0에서:

1. vecnorm 를 norm 로, vecdot 를 dot 로 지원 중단합니다. (1.0 릴리스 규칙 @StefanKarpinski에서 이것이 허용되는지 확실하지 않습니까?)

(놀랍게도 numpy.inner 함수는 항상 내부 곱이 아닙니다 . 그러나 inner 및 dot 에 대한 NumPy의 용어는 한동안 이상했습니다.)

계속해서 dot 로 쓰는 것을 선호하는 이유:

• 띄어쓰기가 있는 것이 좋습니다.
• 일반 유한 차원 벡터 공간에서 작업하는 수학자가 아닌 경우 dot 는 유클리드 내적에 대해 더 친숙한 이름입니다. (수학자들은 임의의 힐베르트 공간에서 내적 함수에 dot 라는 이름을 사용하는 것에 쉽게 적응할 것입니다. "내적"은 그러한 공간에 대한 다른 가능한 의미가 없습니다.)
• inner 와 dot 가 모두 있으면 혼동될 수 있습니다. 어떤 경우에는 일치하지만 다른 경우에는 일치하지 않을 수 있기 때문입니다(현재 dot 의미를 유지한다면).
• 선형 대수 외에도 inner 는 컴퓨터 과학에서 많은 다른 잠재적 의미를 가지고 있으므로 Base에서 이 이름을 내보내는 것은 다소 성가신 일입니다.

inner라는 이름에 대한 반대 의견을 자세히 말씀해 주시겠습니까? 나는 아직도 이해하지 못한다
이 스레드의 모든 사람들이 용어에 반대하는 것을 선호하는 이유는
동의합니다?

2018년 5월 15일 화요일 오전 5:13 Steven G. Johnson [email protected]
썼다:

(numpy.inner
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
놀랍게도 함수가 항상 내적 제품은 아닙니다 .)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
.

어떤 이유도 나에게 설득력이 없습니다.

>

• 중위 변형이 있는 것이 좋습니다.

예, 중위 표기법은 다음으로 이름을 바꾸더라도 여전히 존재할 수 있습니다.
위에서 설명한 내부.

>

• 일반 유한 차원에서 작업하는 비수학자용
  벡터 공간, 점은 유클리드 내부에 대한 더 친숙한 이름입니다.
  제품. (수학자들은 점이라는 이름을 사용하는 것에 쉽게 적응할 것입니다.
  임의의 힐베르트 공간에 대한 내적 함수 - "내적"에는
  그러한 공간에 대한 다른 가능한 의미.)

이 주장은 좋지 않습니다. 평범한 사람들에게 잘못된 것을 가르치자
그들은 게으르고 새로운 적절한 단어를 배울 수 없기 때문에 용어,
수학자들이 자신의 의지에 반하여 잘못된 용어를 사용하도록 강요합니다.

>

• 내부와 점이 모두 있으면 혼란스러울 수 있습니다.
  어떤 경우에는 일치하지만 다른 경우에는 일치하지 않을 수 있습니다(현재 점을 유지하는 경우
  의미).

우리는 둘 다 필요하지 않습니다. 우리가 동의하는 덜 일반적인 이름을 제거하십시오.
이때 점.

>

• 선형 대수 외에도 내부에는 다른 가능성이 많이 있습니다.
  컴퓨터 과학의 의미, 따라서 그것은 다소 성가시다.
  Base에서 이 이름을 내보냅니다.

선형 대수학 외에 점에 대한 많은 용도를 찾을 수 있습니다. 를 위해 더욱
완전히 다른 것을 의미하는 점 중위 표기법.

>

고정된 형식으로 @juliohm 의 마지막 게시물을 다시 게시하고 있습니다.

어떤 이유도 나에게 설득력이 없습니다.

중위 변형이 있는 것이 좋습니다.

예, 그리고 위에서 설명한 대로 inner로 이름을 바꾸더라도 중위 표기법은 여전히 ​​존재할 수 있습니다.

일반 유한 차원 벡터 공간에서 작업하는 수학자가 아닌 경우 점은 유클리드 내적에 대한 더 친숙한 이름입니다. (수학자들은 임의의 힐베르트 공간에서 내적 함수에 점이라는 이름을 사용하는 것에 쉽게 적응할 것입니다. "내적"은 그러한 공간에 대한 다른 가능한 의미가 없습니다.)

이 주장은 좋지 않습니다. 평범한 사람들이 게으르고 새로운 적절한 단어를 배울 수 없기 때문에 잘못된 용어를 가르치고, 수학자들이 자신의 의사에 반해 잘못된 용어를 사용하도록 강요합시다.

내부와 점이 모두 있으면 혼동될 수 있습니다. 어떤 경우에는 일치하지만 다른 경우에는 일치하지 않을 수도 있기 때문입니다(현재 점의 의미를 유지하는 경우).

우리는 둘 다 필요하지 않으며 덜 일반적인 이름을 제거합니다. 우리는 이 시점에서 동의합니다.

선형 대수 외에도 inner는 컴퓨터 과학에서 많은 다른 잠재적 의미를 가지고 있으므로 Base에서 이 이름을 내보내는 것은 다소 성가신 일입니다.

선형 대수학 외에 점에 대한 많은 용도를 찾을 수 있습니다. 완전히 다른 것을 의미하는 점 중위 표기법의 경우 더욱 그렇습니다.

예, 그리고 위에서 설명한 대로 inner로 이름을 바꾸더라도 중위 표기법은 여전히 ​​존재할 수 있습니다.

확실히 const ⋅ = inner 정의할 수 있지만 용어가 일치하지 않습니다. '내적'을 일반적인 내적 제품으로 사용하는 것을 좋아하지 않는다고 생각했나요?

수학자들이 자신의 의지에 반해 잘못된 용어를 사용하도록 강요

수학자들은 용어가 옳거나 그르지 않고 단지 관습적이거나 비관습적(일관되거나 일관성이 없을 수 있음)일 뿐이라는 것을 알고 있습니다. (그리고 대부분의 사람들은 철자법에 대한 열정이 있기 때문에 수학에 가지 않습니다.) 제 경험에 따르면, 수학자들에게 양자 역학에서 벡터는 "상태"라고 하고, 부수는 "단검"이라고 하고, 이중 벡터는 "브래지어"라고 불리며 숭고하게 무관심합니다. 유사하게, Julia에서 내부 제품의 철자가 dot(x,y) 또는 x ⋅ y 라고 말하면 경험 많은 수학자는 한 번 이상 눈을 깜박일 것이라고 생각하지 않습니다. 특히 용어가 이미 다음과 같이 이해되고 있기 때문입니다. 많은 맥락에서 동의어. (당신이 "이 함수 공간에서 두 함수의 내적을 취하라"고 말하면 당신이 내적을 언급하고 있다는 것을 즉시 알지 못하는 수학자를 찾을 수 있을지는 의문입니다.)

다른 한편으로, 훈련된 수학자도 아니고 추상적인 내부 제품 공간에 노출 되지 않은 사람들(즉, 대다수의 사용자)에게는 익숙하지 않은 용어 가 더 큰 장애물입니다. "줄리아에서 두 벡터의 내적은 어떻게 구합니까?" FAQ가 됩니다.

여기서 의미론을 선택하는 것 외에 해결해야 할 수학적 어려움은 없습니다. 철자 문제는 순전히 편의와 사용법에 관한 것입니다.

선형 대수학 외에 점에 대한 많은 용도를 찾을 수 있습니다. 완전히 다른 것을 의미하는 점 중위 표기법의 경우 더욱 그렇습니다.

Julia와 다른 많은 프로그래밍 언어가 몇 년 동안 dot 를 갖고 있다는 점을 제외하고는 문제가 되지 않았습니다. inner 는 새로운 파손입니다.

궁극적으로 이(또는 다른) 함수의 철자는 의미 체계 및 사용 중단 경로에 비해 사소한 문제이지만 균형이 dot 에 유리하다고 생각합니다.

const ⋅ = inner를 확실히 정의할 수 있지만 용어가 일관성이 없습니다. '내적'을 일반적인 내적 제품으로 사용하는 것을 좋아하지 않는다고 생각했나요?

나는 당신이 아직도 그것을 이해하지 못한다고 생각합니다. 내적 내적을 호출하는 데 불일치가 없습니다. 그것은 우리 중 많은 사람들에게 매우 구체적이고 쓸모없는 내부 제품입니다. sum(x.*y) 이상 없습니다.

dot 라는 용어가 Julia에서 inner 의 의미를 갖는 것으로 끝나는 경우 이것은 많은 사람들이 짜증을 느낄 것이라고 장담할 수 있는 역사적 재앙이 될 것입니다. 저는 교실에서 교수들이 다음과 같이 설명하는 것을 볼 수 있습니다. "이제 우리 공간의 내부 제품을 정의할 것이지만 Julia에서는 누군가(@stevengj)가 그것을 점이라고 부르기로 결정했습니다."

나중에 참조할 수 있도록 이 스레드를 스크린샷으로 찍을 것입니다.

당신은 dot 용어를 주장하는 유일한 @stevengj 이며, 다른 누구도 이에 반대하지 않았습니다. 결정을 내리기 전에 이 사실을 다시 생각해 볼 수 있다면 좋을 것입니다.

그것은 우리 중 많은 사람들에게 매우 구체적이고 쓸모없는 내부 제품입니다. sum(x.*y) 이상입니다.

"내적"이 ℝⁿ의 유클리드 내적만 참조할 수 있다고 생각한다면 const ⋅ = inner 를 정의해서는 안 되며 ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) 만 정의해야 합니다.

두 가지 방법으로 사용할 수는 없습니다. inner 는 ⋅ 를 중위 동의어로 사용할 수 있습니다(이 경우 중위 연산자는 귀하의 말투에서 "잘못"되고 이름 지정이 일관되지 않음) 또는 중위 동의어 가 없습니다(하나의 특별한 경우 제외).

저는 교실에서 교수들이 다음과 같이 설명하는 것을 볼 수 있습니다. "이제 우리 공간의 내부 제품을 정의할 것이지만 Julia에서는 누군가(@stevengj)가 그것을 점이라고 부르기로 결정했습니다."

하하, 나는 이 상상의 화난 교수에게서 열을 받아 들일 용의가 있다. 진지하게, "내적"이라는 용어가 ℝⁿ에서만 사용되었다고 생각하거나 그 용어가 다른 Hilbert 공간에서 사용되는 경우 수학자들이 분노한다고 생각한다면 더 둘러볼 필요가 있습니다.

이것은 역사적 재앙이 될 것이다

진지하게?

이 논의는 환영하고, 시민적이며 건설적인 환경 이라고 생각할 수 있는 것 이상으로 침식되고 있는 것 같습니다. 의견과 배경은 다르지만 인신공격이나 누구를 탓하는 것은 삼가하시고 모든 당사자가 선의로 자신의 주장을 의논하고 있다고 가정해 주십시오.

저는 교실에서 교수들이 다음과 같이 설명하는 것을 볼 수 있습니다. "이제 우리 공간의 내부 제품을 정의할 것이지만 Julia에서는 누군가(@stevengj)가 그것을 점이라고 부르기로 결정했습니다."

여기에서 Steven이 교수임을 주목하는 것도 가치가 있을 수 있습니다. :눈짓:

나는 또한 inner dot 를 제거하는 것에 대해 논의 중입니다. dot 용어는 상당히 널리 사용되며 Julia에 함수가 없으면 Python 및 MATLAB에 있을 때 놀라운 일이 될 것입니다. 그러나 inner 라는 용어도 마음에 듭니다. ℝⁿ가 아닌 벡터 공간, 특히 행렬에 더 적합하기 때문입니다.

덧붙여서, Julia에서 메서드가 무엇을 하는지 테스트하는 동안 dot 는 실제 벡터/행렬에서만 작동한다는 것을 알았습니다. 의도적인가요?

내부와 점이 모두 있으면 혼동될 수 있습니다. 어떤 경우에는 일치하지만 다른 경우에는 일치하지 않을 수도 있기 때문입니다(현재 점의 의미를 유지하는 경우).

@stevengj vecdot 를 inner 로 바꾸고 $# dot 도 유지하는 것이 완전히 터무니없습니까? 바로 지금, 귀하가 설명하는 정확한 문제는 inner vecdot 로 이미 존재합니다.

알겠습니다... 기대합니다. 실시간 제안은 무엇인가요? 그들은:

• dot 를 더 넓은 범위의 유형에 대한 일반적인 내부 제품으로 수용합니다. 벡터의 벡터에서는 이미 올바르게 재귀적이지만 행렬 등에서 작동하게 만들 것입니다( @jebej dot 와 inner 둘 다 가지고 있는 것 같지는 않습니다). Steven은 우리가 내부 제품을 의미하기 위해 최소한 dot 를 구어체로 사용하며 이것은 잘못된 것이 아니라 단지 용어일 뿐이라고 말합니다.
• norm 를 위의 dot 와 모든 AbstractArray 에 걸쳐 좀 더 일관성 있게 만드는 것을 고려해보세요. 결국 opnorm 연산자 규범을 도입합니다( AbstractMatrix ). norm(matrix) == vecnorm(matrix) (신규-구식 표기법)를 사용합니다. 이 시점에서 아마도 vecdot 및 vecnorm 가 더 이상 필요하지 않습니까?

맞나요? 내 생각에 이것들은 적어도 "깨끗한" 인터페이스를 사용하여 비교적 일관된 선형 대수학 이야기를 얻을 수 있다고 생각합니다. 여기서 일반 코드는 내부 제품 공간 작업을 위한 안정적인 쌍으로 dot 및 norm 를 사용할 수 있습니다. 유형과 무관합니다.

@andyferris , 예, 이렇게 변경하면 dot 및 norm 만 필요하다고 생각합니다(이제는 모든 차원의 배열 또는 배열에 대한 재귀 유클리드 연산이지만 규범의 경우 norm(x,p) 도 p-norm) 및 opnorm 로 정의하고 더 이상 vecdot 또는 vecnorm 가 없습니다.

dot 로의 변경은 현재 dot 가 #22220(#22220( 그 시점에서 vecdot 를 제거하는 것은 IIRC로 간주되지 않았습니다. 그러나 이는 0.7에서 도입되었으므로 실제 릴리스된 코드를 손상시키지 않습니다. 사실, 0.6의 dot 는 이미 임의 차원 배열의 유클리드 내적입니다. 어느 정도 우연입니다(#22374). 여기서 제안된 변경 사항은 해당 0.6 동작을 복원 및 확장하고 norm 를 변경하여 일치하도록 합니다.

한 가지 질문은 norm(x,p) 가 norm(x[i]) 또는 norm(x[i],p) 재귀적으로 호출할지 여부입니다. 둘 다 잠재적으로 유용한 동작입니다. 나는 전자가 더 일반적이기 때문에 전자에 기대고 있습니다 x[i] 는 p-norm이 아닌 norm 만 정의하는 임의의 표준 벡터 공간일 수 있습니다. norm 를 재귀적으로 호출하는 것도 vecnorm 가 현재 하는 일이므로 vecnorm 를 norm 로 사용하지 않는 것과 일치합니다.

@jebej , dot 마스터 및 0.6 모두 복잡한 배열에서 작동합니다. 예를 들어 dot([3im],[4im]) 는 12+0im $ 를 올바르게 반환합니다.

norm(matrix) 를 Frobenius 표준으로 변경하는 것에 대한 또 다른 좋은 점은 훨씬 저렴하다는 것입니다. 두 행렬의 차이가 얼마나 큰지 알기 위해 norm(A-B) 를 사용하는 것이 일반적이지만 특정 표준 선택에 대해서는 그다지 신경 쓰지 않지만 많은 사용자는 현재 기본값이 norm(matrix) 는 SVD를 계산해야 합니다.

몇 가지 주요 사항을 중심으로 합의가 형성되는 것을 보는 것은 멋진 일입니다! :) (누군가가 나를 능가하지 않는 한(대역폭이 있는 경우 수행하십시오!) 이전에 알파 태그가 히트하지 않는 한, #26997 배송 후 현재 합의 포인트를 구현하도록 하겠습니다.) 최고!

향후 참조를 위한 또 다른 링크: https://math.stackexchange.com/a/476742

여기에 의식적 으로 채택되고 있는 잘못된 명명과 한 마음에 의해 부과된 잘못된 결정을 설명하기 위해. 내적과 내적은 수학적 속성이 다릅니다. 당신은 수학 문헌에서 잘 알려진 것에 반대하는 전체 커뮤니티를 강요하고 있습니다.

그리고 미래의 독자들을 위해, 우리가 공동 결정을 했다면 대신 무엇을 했어야 했는지:

# make dot what it is, a NOTATION
⋅(x::AbstractVector, y::AbstractVector) = sum(x[i]*y[i] for i in indices(x))

# replace the name dot by the more general inner
inner(x, y) = # anything

나는 우리 가 우주 에서 ℝⁿ 이외의 모든 것에 내적에 대해 "내적" 이라는 용어 를 사용 하는 최초 의 사람들 이 될 것이라고 생각합니다. 이 혁신을 세상에 내놓기 위해 (주로 다른 개발자들을 협박함으로써) 이 스레드에 내 의지를 강요할 수 있었던 것은 좋은 일입니다! 내적은 더 이상 단순한 "표기법"으로 분류되지 않습니다. 대신 내적을 의미하는 기호가 됩니다(모두가 알고 있듯이 기호에 의미를 할당하는 것은 "표기법"의 반대임).

아주 좋은 의사결정 :박수: 확실히 합의였습니다. 위의 댓글을 읽으면 모두가 어떻게 동의했는지 알 수 있습니다. :+1:

또는 어떻게 합의가 되었는지 매우 명확하게 일부 의견을 인용해야 할 수도 있습니다.

>

오른쪽 - vecdot의 이름을 inner로 변경할 수 있습니다.

@andyferris 에 의해

옵션 2(아마도 더 나음): 수학적으로 더 정확한 이름을 사용합니다.

안의
치수
그러나 규범으로 무엇을해야합니까?

@Jutho 에 의해

동의합니다. vecdot의 대안으로 내부에 새로운 방법을 도입할 수 있습니다.

@Jutho 에 의해

나는 또한 vecdot 이름이 이상하다는 것을 알았습니다. 사실, 나는 그것이 존재하는지조차 몰랐고 그것에 대한 내 자신의 기능을 만들었습니다... inner라고 합니다.

@jebej 에 의해

그리고 더 많은...

사람들은 서로 큰 소리로 토론할 수 있고 많은 불일치 지점을 제기할 수 있지만 설득을 받고 찬반 양론의 균형을 유지함으로써 여전히 합의에 도달합니다(항상 만장일치는 아니지만). (여기에는 각 옵션의 장단점이 모두 있다는 점에 동의합니다.) 여기에서 (잠정적으로!) 젤처럼 보이는 결과가 원하는 결과가 아닌 것이 유감이지만 어떻게 생각하시는지 잘 모르겠습니다. 나는 내 의지를 "부여"했다.

(물론 최종 결정이 내려진 것은 아닙니다. 아직 PR도 없고 병합된 것도 훨씬 적습니다.)

나는 우리가 언어의 청중을 기반으로 결정을 내릴 수 있기를 바랄 뿐입니다. 누군가 Julia를 도구로 선택한다면 그 사람은 최소한 inner 제품이라는 용어를 들어봤을 것입니다. 그것은 꽤 대중적인 개념이며 이국적이라는 것과는 거리가 멉니다. 이국적인 것들에는 "지속적 상동성", "양자 이론"이 포함됩니다. 이것은 덜 널리 퍼져 있으며 저는 이러한 유형의 용어를 포함하는 것을 반대합니다.

결국 저는 과학 컴퓨팅, 수학 등을 위한 최고의 언어인 언어를 갖고 싶습니다.

@juliohm , 모든 주장은 우리가 생각하는 청중의 필요에 기반했으며 우리 모두는 Julia를 가능한 한 좋은 언어로 만들려고 노력하고 있습니다. 수학은 철자를 결정하지 않기 때문에 합리적인 사람들은 용어에 대해 다른 결론에 도달할 수 있습니다.

첫째, 위에서 언급했듯이 @stevengj 의 현재 제안에 확실히 동의하고 내부 제품의 일반 이름으로 dot 를 고수합니다. 또한 저는 이 토론이 진행되는 방식이 마음에 들지 않으며 올바르게 인용되기를 원합니다. @juliohm , 당신이 나에게 부여한 두 번째 인용문은 내 것이 아닙니다.

그런 의미에서 찬반 양론을 생각하면서 다음과 같은 점을 언급하고자 한다. 다음은 대부분 단점이지만 @stevengj가 언급한 장점에 동의합니다. dot 가 sum(x[i]*y[i] for i ...) 를 의미하는 별도의 사용 사례가 쉽게 있을 수 있습니다. 중위 점 표기법이 수학에서 가장 많이 사용되는 경우 실제로 이것이 일반적으로 의미입니다. 내부 곱으로서, 중위 점 표기법은 일반적으로 (확실히 배타적이지는 않지만) 실수 벡터 공간에 예약되어 있습니다. 다른 사용 사례에는 σ $$$ σ ⋅ n n 스칼라 벡터와 같은 것을 활성화하는 것이 포함됩니다. 이것은 다른 스레드에서 나에게 지적된 바와 같이 현재 dot 가 구현되는 방식 뒤에 있는 동기 중 하나입니다. BLAS가 실수 벡터에 대해 dot 만 사용하고 복소수 벡터에 대해 dotu 와 dotc 를 구분하기로 결정했다는 사실은 고려해야 할 또 다른 문제입니다. BLAS 배경을 가진 사람들은 복잡한 벡터를 사용하여 진정한 내적(예: dotc )을 원할 때 dot(conj(u),v) 또는 dot(u,v) 를 계산할지 혼동할 수 있습니다. 게다가, 그들은 손에 있는 벡터의 켤레 복사본을 먼저 만들지 않고 dotu 를 수행하는 방법을 찾을 수 있습니다.

@Jutho 견적은 귀하의 것이며 귀하의 전체 의견은 아래에 복사됩니다.

vecdot의 대안으로 새로운 내부 메서드를 도입할 수 있다는 점에 동의하지만 vecnorm을 "대체"하는 좋은 이름을 모르겠습니다. 사실, 나는 vecnorm이 그렇게 나쁘다고 생각하지 않습니다. 벡터 노름은 우리가 원하는 작업에 대해 잘 확립되고 명시적인 용어입니다.

어쨌든, 인용은 우리가 이 주제에 대해 생각할 때 여기에서 많은 사람들이 바라는 것이 무엇인지(적어도 최초의 자연스러운 생각으로서) 보여주기 위한 것입니다. 시간이 지남에 따라 욕망이 바뀌었다면 그것은 또 다른 이야기입니다. 나 자신은 Hilbert 공간을 사용하여 모델링하는 동안 내 머리에서 "점"이라는 용어를 절대 꺼내지 않을 것입니다. 내가 배운 것과 일치하지 않고 부자연스럽게 느껴진다.

@Jutho : 게다가, 그들은 손에 있는 벡터의 켤레 복사본을 먼저 만들지 않고 dotu 를 수행하는 방법을 찾을 수 있습니다.

dotu 기능을 내보낼 수 있는 가능성이 때때로 제기되었습니다(예: #8300 참조). 나는 이것이 때때로 유용한 함수라는 데 동의합니다. 복잡한 벡터 공간에 대해서도 대칭 쌍선형(세퀴선형이 아님) 형태인 비공액 유클리드 "내적"(실제로는 더 이상 내적이 아님) dotu(x,y) == dotu(y,x) (공액 아님) . 그러나 그 연산의 유용성은 ℂⁿ에 국한되지 않습니다. 예를 들어, 이러한 종류의 곱은 종종 상호성 의 결과로 Maxwell 방정식에 대한 무한 차원 벡터 공간(함수)에 나타납니다(기본적으로: 일반적인 손실 재료의 Maxwell 연산자는 "복소 대칭 행렬"과 유사 - 공액되지 않은 "내적"에서 대칭). 따라서 dot(x,y) 를 일반 유클리드 내적(첫 번째 인수가 켤레됨)으로 정의하면 모든 벡터 공간에서 비공액 유클리드 곱에 대해 dotu(x,y) 함수를 정의하는 것이 매우 자연스럽습니다. 그것이 의미가있는 곳. 그러나 dot 에 대한 인수로 dotu 함수의 가능성은 보이지 않습니다. 대부분의 경우 복잡한 벡터 공간으로 작업할 때 공액 곱을 원하므로 이것이 올바른 기본 동작입니다.

그러나 한 가지 가능성은 dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) 를 정의하는 것인데 이것이 현재 마스터에서 정의된 방식(0.6 아님)이고 inner(x,y) 를 진정한 내적으로 정의하는 것입니다. 이것은 두 기능을 모두 제공하는 이점이 있으며, 둘 다 특정 경우에 유용할 수 있습니다. 그러나 행렬 배열을 제외하고 거의 항상 일치하는 두 가지 함수가 있으며 둘 중 하나를 사용할 시기를 결정하는 것이 약간 혼란스러울 것 같습니다. 많은 사람들이 inner 를 의미할 때 dot 라고 쓰고 대부분의 경우 잘 작동하지만 행렬 배열이 전달되면 코드에서 예기치 않은 작업을 수행합니다. 내 의심은 99%의 경우 사람들이 진정한 내부 제품을 원하고 "제품의 합계" 버전이 실제로 필요한 경우 패키지에 남겨둘 수 있다는 것입니다(단지 sum 를 호출하는 것과는 대조적으로) ).

@juliohm , 이름이 각각의 인용문 위에 (아래 대신) 있다고 생각하여 귀하의 게시물을 잘못 읽었으므로 @jebej 의 인용문이 저에게 있다고 생각했습니다. 죄송합니다.

@stevengj , 나는 확실히 dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) 를 합리적인 기본값으로 생각하지 않았습니다. σ ⋅ n 와 같은 경우 첫 번째 또는 두 번째 인수의 복소수/은수 켤레가 필요하지 않습니다. 그래서 내가 말하고자 하는 것은, 중위 점 표기법이 과학 공식에 사용되는 많은(그러나 실제로 전부는 아님) 경우에 그 의미가 dotu , 즉 활용 없이 sum(x[i]*y[i] for i = 1:length(x)) 와 일치한다는 것입니다. 실제 벡터 공간의 내적 또는 좀 더 일반적인 구성으로.

따라서 내가 대안 제안을 한다면(반드시 옹호하지는 않지만) 두 가지 기능이 있습니다.

• dot(x,y) = sum(x[i]*y[i] for i...) , 이는 여전히 실제 벡터에 대한 올바른 내적이지만(내적이라는 용어에 익숙하지 않거나 익숙하지 않은 사람들의 사용 사례일 가능성이 있음) σ ⋅ n 와 같은 보다 일반적인 구성도 허용합니다.

• inner(x,y) 는 활용 및 재귀가 포함된 항상 유효한 내부 제품으로 보다 일반적인 기술 컨텍스트에서 사람들이 사용할 것입니다.

나는 이것을 Julia Language에서 채택하기에 좋은 선택이라고 옹호하지는 않지만 이것이 많은 문헌에서 사용되는 방식이라고 생각합니다. 중위 점이 사용되면 실수 벡터의 맥락에서 내적으로 사용되거나 수축을 의미하는 좀 더 일반적인 구성에서 사용됩니다. 임의의 벡터 공간에 대한 일반적인 내적을 의도할 때 대부분의 과학 문헌(그러나 확실히 반대 예를 보여 주었습니다)은 <u,v> 또는 <u|v> 로 전환됩니다(여기서 첫 번째 표기법에는 여전히 다음과 같은 논의가 있습니다. 두 인수 중 켤레).

나는 이 제안으로 살 수 있었지만, 나는 단지 dot 를 일반 내부 제품으로 가지고도 똑같이 잘 살 수 있었습니다. 결국, 그것은 좋은 문서를 가지고 있는 문제이고, 나도 누군가가 이 "디자인" 선택에 걸려 넘어질 것이라고 믿을 수 없습니다.

@Jutho , 나는 dot 를 수축을 의미하는 것으로 정의하는 것이 드문 일이 아니라는 데 동의합니다. 물론 두 가지 방법 모두에서 예를 찾을 수 있습니다. 예를 들어, 프로그래밍 언어와 대중적인 라이브러리에서:

• 비결합: Numpy dot (그리고 기이하게도 내부 ), Mathematica의 Dot , Maxima . , BLAS dotu

• 활용: Matlab의 dot , Fortran의 DOT_PRODUCT , Maple의 DotProduct , Petsc의 VecDot , Numpy vdot , BLAS dotc ( Fortran 77의 오버로딩은 원하더라도 이것을 dot 라고 부르는 것을 불가능하게 만들었습니다.), Eigen's dot

한편, 공액 내적은 일반적으로 교과서에서 복잡한 벡터에 대한 "내적" 개념 의 "자연적" 확장으로 소개됩니다. 당신이 원하는 것. (Matlab, Fortran, Julia, Maple과 같은 표준 라이브러리에서 conjugated dot 함수를 제공하는 언어 중 Maple만이 unconjugated 변형을 제공하여 수요 부족을 암시한다는 사실을 고려하십시오.) 반면에, 비공액 dotu 함수는 특정한 특별한 경우(일부는 위에서 언급한)에서 (보충으로) 편리합니다.

dot 와 inner 가 모두 있는 경우 많은 사람들이 자신의 코드가 inner 이기를 원할 때 실수로 dot 를 사용하게 될 것이라고 생각합니다. 일반적인. (나는 Numpy의 inner 가 바로 그런 사고로 인해 비공액일 것이라고 장담합니다. 그들은 실제 배열을 염두에 두고 구현했으며 변경하기에 너무 늦을 때까지 복잡한 경우에 대해 생각하지 않았으므로 추가했습니다. 어색하게 명명된 vdot .) 반면에 dot 및 (아마도) dotu 가 있는 경우 dot 가 기본 선택이고 dotu 는 특수한 경우 변형입니다.

( ⟨u,v⟩ , ⟨u|v⟩ 또는 (u,v) 가 임의의 Hilbert 공간에서 내부 제품에 대한 더 일반적인 표기법이라는 데 동의합니다. 이러한 표기법은 제가 일반적으로 사용하는 것입니다. 그러나 이러한 표기법은 Julia의 nonstarter. 유니코드 대괄호를 함수/매크로 호출로 구문 분석하는 것에 대한 토론이 있었습니다(예: #8934 및 #8892, 하지만 아무데도 가지 않았으며 이것은 곧 변경될 것 같지 않습니다.)

귀하의 평가에 전적으로 동의합니다 @stevengj .

나도.

나는 우리 중 한 명이 PR에서 두 구현 중 하나를 가지고 놀고 그것이 어떻게 나오는지 봐야 할 때라고 생각합니다.

@Jutho 저는 항상 Pauli 행렬이 있는 내적을 고차 텐서에 대한 수축의 약어로 보았습니다... 벡터 공간 중 하나는 실제 3D입니다.

나는 ⟨u,v⟩, ⟨u|v⟩, 또는 (u,v)가 임의의 힐베르트 공간에 대한 내적에 대한 보다 일반적인 표기법이라는 데 동의합니다. 이러한 표기법은 제가 일반적으로 사용하는 표기법입니다. 그러나 이러한 표기법은 Julia에게는 시작하기 어려운 표기법입니다.

실제로 ⟨u,v⟩ 가 작동하도록 하는 것이 가능합니다.

@StefanKarpinski : 실제로 ⟨u,v⟩가 작동하도록 할 수 있습니다.

물론 이 정확한 표기법을 뒷받침하는 것은 #8934에서 제안되었지만 아무데도 가지 않았습니다. (또한 꺾쇠괄호는 다른 일반적인 용도를 가지고 있다는 점에 유의하십시오. 예를 들어 ⟨u⟩는 종종 어떤 종류의 평균을 나타냅니다.) 이것은 깨지지 않으며 여전히 어느 시점에서 추가될 수 있지만 가까운 시일 내에 예상하는 것이 합리적이지 않은 것 같습니다. 기간. 또한 \langle<tab> x, y \rangle<tab> 를 입력하는 것도 매우 느리기 때문에 기본 연산에 대한 프로그래밍 관점에서 그리 편리하지 않습니다.

그리고 우리는 그것에 대해 <>를 오버로드할 수 없습니다. 그렇죠?

아니요

이 엄청난 스레드에 대한 모든 댓글을 읽었다고 말할 수는 없지만 몇 가지 요점을 강조하고 싶습니다. 그 중 일부는 이전에 작성되었습니다.

• 점과 내부를 구분하는 것은 지나치게 현학적인 것 같습니다. 프랑스어에는 "스칼라 곱"이라는 용어가 하나만 있기 때문에 내 귀에는 무의미하게 보입니다. 그리고 나에게는 같은 이름을 가진 것들을 구별하기 어렵습니다 ;-)
• numpy에서 와서 복잡한 배열로 작업할 때 dot 가 기본적으로 활용되는 것이 가장 좋습니다. 여기에 결정 포인트가 없습니다. 더 이상 이러한 conj(dot()) 작업을 수행할 필요가 없다는 것이 얼마나 다행인지 말하고 싶었습니다!
• 대부분의 경우 동일한 동작을 갖지만 때로는 다른 두 가지 기능을 갖는 것은 잘못된 설계이며, 단순히 사용자가 더 잘 알지 못하기 때문에 하나를 호출해야 하는 코드가 실제로 다른 하나를 호출하는 것과 혼동을 일으킬 수 있습니다. 이것은 norm 에서 특히 성가신 일입니다. 최적화 알고리즘을 코딩하고 norm(delta x) < eps 때마다 중지하려는 경우 norm 를 작성하게 됩니다. 하지만 이미지나 무엇인가를 최적화하고 싶고 코드를 실행하면 갑자기 큰 배열의 죽일 수 없는(BLAS 때문에) SVD로 시작됩니다. 이것은 학문적이지 않고 Optim.jl에서 문제를 일으키고 의심할 여지 없이 다른 패키지에서도 문제를 일으켰습니다. vecnorm를 찾는 특별한 이유가 없는 한 아무도 vecnorm 가 있다는 것을 알지 못할 것입니다.
• 이전 요점을 기반으로 dot 및 vecdot 및 norm 및 vecnorm 를 병합하는 솔루션은 약간의 유연성을 제거하더라도 좋습니다. 배열의 경우. 규범의 경우 정의된 여러 규범(예: 행렬)이 있는 작업을 할 때 사용자가 원하는 것은 규범을 얻기 위해 특히 신경 쓰지 않고 norm 를 호출하는 것입니다. 유도된 규범은 계산의 난해성으로 인해 실제보다 이론적인 경우가 대부분입니다. 그것들은 또한 2D 어레이를 스토리지로 해석하는 것이 아니라 2D 어레이를 연산자로 해석하는 데 고유합니다(이미지는 2D 어레이이지만 유용한 의미에서 연산자는 아닙니다). 그것들을 계산할 가능성이 있는 것은 좋지만 기본 norm 가 될 자격이 없습니다. 발견할 수 있는 대안이 있는 합리적이고 간단하며 잘 문서화된 기본값은 시도된 영리함보다 낫습니다(사용자가 영리한 일을 하고 싶다면 명시적으로 하도록 하십시오).

따라서 @stevengj 의 +1

예, 이 변경을 수행하면 점과 노름만 필요하다고 생각합니다(지금은 모든 차원의 배열 또는 배열에 대한 재귀 유클리드 연산이지만 규범의 경우 norm(x,p)도 다음과 같이 정의합니다. p-norm) 및 opnorm이 있으며 더 이상 vecdot 또는 vecnorm이 없습니다.

norm/opnorm에 대한 더 "줄리안" 대안은 norm 가 opnorm을 수행하는 2D 배열을 래핑할 수 있는 연산자 유형을 갖는 것일 수 있습니다. 이것은 패키지 수준에서 수행할 수 있습니다(몇 개는 이미 존재함)

norm(Operator(matrix)) opnorm(matrix) 를 입력하고 싶습니다 …

나는 여기 땅콩 갤러리에서 차임벨을 들고 이것이 가고 있는 곳이 마음에 든다고 말할 것입니다 vecnorm 와 vecdot 는 항상 저를 괴롭혔습니다. 항상 나에게 상당히 전문화된 것처럼 보였던 연산자 노름을 명시적으로 요구하는 것이 훨씬 빠르고 계산하기 쉬운 노름(예: Frobenius 노름)을 요구하는 것보다 훨씬 건전해 보입니다. opnorm 를 작성하는 것은 상대적으로 전문화된 연산자 규범을 요구하는 훌륭한 인터페이스처럼 보입니다.

또한 dot 와 inner 를 미묘한 차이로 구분하면 혼란과 오용이 만연할 수 있다고 생각합니다. 두 기능이 모두 원하는 대로 수행되고 그 중 하나가 더 쉬울 때 어떤 기능을 사용해야 하는지 사용자에게 강의하는 것은 잘 작동하지 않는 경향이 있습니다. 내 인상은 진정한 내부 제품 ⟨u,v⟩ 이 실제로 존재할 때 sum(x*y for (x,y) in zip(u,v)) 가 실제로 원하는 것이 제네릭 코드에서 상대적으로 드물다는 것입니다. 그것이 정말로 원하는 것일 때 계산하기 위해 이와 같은 것을 작성하는 것이 상당히 쉽고 명확하고 효율적입니다(Julia가 바로 그런 사람이기 때문입니다).

u⋅v 함수 dot 또는 inner 호출할지 여부는 이 모든 것에서 가장 덜 중요한 부분처럼 보입니다. 역사가들이 어떤 선택도 재앙으로 보지 않을 것이라고 나는 확신합니다. 역사가들이 전혀 관심을 가질 것이라는 생각은 확실히 아첨입니다. 한편으로 u⋅v 의 "진정한 내적" 의미를 유지하는 데 동의한다면 예, inner 가 더 정확한 수학 용어입니다. 반면에 해당 함수 이름이 있는 구문이 있는 경우 이름이 구문과 일치할 때 사용자를 덜 혼동시키는 경향이 있습니다. 여기에서 구문은 점을 사용하기 때문에 경험상 이 작업의 철자를 dot 로 지원합니다. const dot = inner 를 정의하고 둘 다 내보내는 것이 합리적인 경우일 수 있습니다. 그런 다음 사람들은 동일한 이름이므로 원하는 이름을 사용하거나 확장할 수 있습니다. 누군가가 두 이름 중 하나를 다른 이름으로 사용하려는 경우 다른 이름은 기본 의미로 계속 사용할 수 있습니다. 물론 이렇게 하면 동일한 함수에 대해 세 개의 내보낸 이름( dot , inner 및 ⋅ )이 만들어집니다. 이는 약간 과도해 보입니다.

⋅ 기호를 제거하거나 <u,v> 로 대체하는 옵션입니까?

코멘트:

• 의도를 분명히 하고 있습니다. 다음 두 예를 비교하십시오.

<u,v> * M * x

대

u ⋅ v * M * x

• <u,v> 구문은 연관을 의미합니다. 먼저 u 및 v 에 대해 작업한 다음 나머지 표현식이 따릅니다.

• 사용자가 <u,v> 를 입력하려고 노력했다면 그가 단순한 sum(x[i]*y[i]) 를 염두에 두었을 가능성은 거의 없습니다. ⋅ 기호는 눈으로 건너 뛰기 쉽고 다른 많은 의미가 있습니다. 특히, 선형 대수학에서 필드 F 위의 벡터 공간 V에 대해 스칼라 α ∈ F 와 벡터 v ∈ V 의 곱은 다양한 교과서에서 α ⋅ v 로 표시됩니다.

• ⋅ 를 제거하거나 바꾸면 여러 이름을 내보내는 문제도 제거됩니다. 일반 내부 제품에 대해 inner 및 <,> 내보내야 하며, 반복 가능한 합계 의미 체계와 일치하는 배열에 대한 기본 구현이 있습니다.

• 필드 F에 대한 벡터 공간 V에 대해 위에서 설명한 것처럼 스칼라 대 벡터 곱을 정의해야 하는 경우 ⋅ 표기법을 정의할 수 있습니다. 그런 다음 벡터 공간은 멋진 짧은 구문으로 완전히 정의되고 <u,v> 를 추가로 정의하여 Hilbert 공간으로 확장할 수 있습니다.

<u,v> 구문을 사용할 수 없습니다. 우리가 사용할 수 있는 구문은 ⟨u,v⟩ 입니다. 유니코드 대괄호, 보다 작거나 큼 기호, < 및 > 에 주의하십시오. 또한 내적 또는 내적에 대한 구문으로 u'v 가 있습니다. (어느 쪽인지는 모르겠지만...)

네, 죄송합니다. 유니코드 버전입니다. 매우 명확하게 읽을 수 있습니다. 또한 여러 이름으로 이 문제를 해결하고 다른 용도로 ⋅ 를 무료로 사용할 수 있습니다.

다른 용도로 ⋅ 를 사용하고 싶지 않다고 생각합니다. 혼란스러울 것 같습니다.

다음과 같은 코드를 작성할 수 있다면 얼마나 좋을까 상상해보십시오.

⟨α ⋅ u, v⟩ + ⟨β ⋅ w, z⟩

추상 벡터(또는 유형) u,v,w,z ∈ V 및 스칼라 α, β ∈ F .

u'v 는 행렬이 아닌 1차원 배열에 대해서만 내적(및 공액 규칙을 따르는 경우 내적)입니다. (이는 이미 해당 경우에 대한 간결한 표기법을 가지고 있기 때문에 중위 점을 1d 배열로 제한하는 것이 무의미한 또 다른 이유입니다.)

Stefan, "정확한 수학적 용어"는 범주 오류입니다. 수학적 정확성은 용어/표기법에 적용되는 개념이 아닙니다. ("정확한"을 "관습적인"으로 대체하십시오. 그러나 걱정은 덜 시급해집니다.)

더 많은 사용 사례: https://stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

⟨,⟩ 표기법을 사용하는 부울 내부 곱의 공식 파생: https://arxiv.org/abs/0902.1290

편집: 종이에 대한 고정 링크

꺾쇠 괄호 구문 제안에 대해 어떻게 생각하십니까? 여기서 제기된 문제가 해결될까요?

그래서 당신의 제안은 정확히 무엇입니까? 대략 이렇습니다.

1. dot 를 inner 로 지원 중단
2. u⋅v 를 ⟨u,v⟩ 로 지원 중단

그렇다면 dot 함수와 ⋅ 연산자가 없을까요?

그것이 합리적으로 바뀌겠습니까?

회신이 늦어 죄송합니다. 인터넷 액세스가 제한된 회의에 참석 중입니다.

그리고 명확성과 완전성을 위해 여기서 반대 제안은 무엇입니까? 아무것도하지 마세요?

제안을 더욱 명확히 하기 위해 의미론적 변화가 수반됩니다: 일반화된 내부 제품.

주의: 우리는 이제 0.7-알파로 만들지 않을 실제 위험이 있는 지점까지 이에 대해 논의했습니다. 그렇다고 해서 알파 이후에 변경할 수 없다는 의미는 아니지만, 그 이후에는 변경하기를 훨씬 더 꺼리게 됩니다.

예, 오래 전에 PR을 제출할 수 있는 기술이 있었으면 합니다. 그것이 매우 중요한 기능이라고 생각하지만 그것을 실현하는 것은 제 능력 밖입니다.

연산자 구문 질문을 할인하더라도 의미 개념의 각 세트(현재 dot 및 vecdot 및 현재 norm 및 vecnorm ).

dot 측면의 경우 옵션의 전체 공간(다시 연산자 할인)은 다음과 같습니다.

I. 0.7의 동작을 표준 depwarn 없이 내부 제품으로 변경하여 배열 벡터에서 dot 를 자동으로 중단합니다(동작이 변경되고 있음을 경고할 수 있음). 0.7에서도 vecdot 를 dot 로 사용 중단합니다.
Ⅱ. 0.7에서 inner 에 대한 모든 입력에서 inner vecdot 를 더 이상 사용하지 않습니다.
III. 0.7에서 배열의 벡터에 대한 dot 정의에 대해, 다른 입력에 대해 dot 및 vecdot 에 대한 모든 입력에 대해 inner 를 더 이상 사용하지 않습니다.
IV. 0.7에서는 내보내지 않은 함수 또는 해당 정의에 대한 배열 벡터의 dot 및 vecdot 및 $#$ dot vecdot 사용을 중단합니다. 1.0에서는 내적 의미 체계가 있는 배열 벡터에 dot 를 추가합니다.

표준 측면의 경우 단일 경로에 대한 합의가 있습니다(0.7에서는 행렬에서 norm 를 opnorm 로 사용하지 않고 vecnorm 에서 innernorm 로 사용하지 않을 수 있음) ; 1.0에서 , 현재 vecnorm 의미 체계가 있는 행렬에 norm 추가), 그러나 1.0에서 추가 이름도 생성됩니다( vecnorm 또는 innernorm ). 이를 방지하는 방법은 0.7에서 vecnorm 의 정의 또는 내보낸 이름이 아닌 Base.vecnorm 와 같은 내보내지 않은 함수를 더 이상 사용하지 않는 것입니다.

...제 생각에는. 내가 이미 있었던 것보다 일을 더 흐릿하게 만들지 않기를 바랍니다.

코드베이스에 익숙한 사람이 변경 사항에 대한 PR을 제출할 수 있습니까?

모든 사람이 동의하는 것으로 보이는 일반적인 항목을 분리하고 최소한 완료할 수 있습니까? dot 대 inner 비트는 훨씬 더 논쟁의 여지가 있지만 그렇지 않은 부분을 방해하지 않도록 합시다.

@StefanKarpinski , 그것들은 다소 결합되어 있음에 유의하십시오. 내적(내부)과 표준이 모두 있는 유형의 경우 일관성이 있어야 합니다.

좋아, 나는 이것이 어떤 방향으로 흘러가든 상관하지 않는다. 작업을 하는 사람이 결정합니다.

나는 vecdot 를 재귀적으로 만들어 진정한 내부 제품(및 해당 표준으로 vecnorm )으로 동작하도록 PR( #25093 )을 했습니다. 이것은 미래의 dot 및 norm 이 어떻게 생겼는지에 대한 출발점으로 유용할 수 있습니다. 불행히도, git 기술이 부족하여 해당 PR을 망쳐버렸고 새로운 반복 구문이 완료된 후에 다시 돌아올 계획을 세우고 닫았습니다.

그러나 며칠 전에 두 번째로 아빠가 된 것은 현재 캘린더에 "여가 시간"이 없다는 것을 의미합니다.

며칠 전에 두 번째로 아빠가 된

축하해 주토! 🎉

예, 축하합니다!

dot 와 inner 가 모두 있다는 아이디어에 대해 합의 가 이루어진 것 같습니다. 여기서:

1. inner 는 진정한 재귀 내부 곱입니다.
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) 결합 여부, 따라서 Vector{<:Number} 또는 Vector{<:Real} 의 경우 dot 와 겹칩니다.

에 관하여:

많은 사람들은 내부를 의미할 때 점을 작성하고 대부분의 경우 잘 작동하지만 행렬 배열이 전달되면 코드에서 예기치 않은 작업을 수행합니다.

나는 그것이 문제가 될 것이라고 믿지 않는다. 이것은 상당히 드문 작업이기 때문에 사람들이 최소한 작업을 수행하고 문서를 살펴보기 위해 시도할 것으로 기대합니다.

dot 의 의미는 대부분의 경우 변경되지 않기 때문에 위의 내용은 큰 변화가 될 것이며 그다지 방해가 되지 않을 것이라고 생각합니다.

dot 및 inner 둘 다 가지고 있다는 아이디어에 대해 합의가 이루어진 것 같습니다.

반대로 https://github.com/JuliaLang/julia/issues/25565#issuecomment -390069503의 토론에서는 https://github에 나와 있는 것처럼 둘 중 하나가 아닌 둘 중 하나를 사용하는 것을 선호하는 것으로 보입니다. com/JuliaLang/julia/issues/25565#issuecomment -390388230 및 반응으로 잘 지원됩니다.

아마도 inner (또한 dot )는 재귀 내부/점/스칼라 곱이어야 하고 이전 동작은 dotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x)) 및 dotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x)) 와 같은 함수에서 구현될 수 있습니다. ? dotu 및 dotc 이름은 해당 BLAS 이름과 일치합니다.

(나는 ⟨u,v⟩, ⟨u|v⟩, 또는 (u,v)가 임의의 Hilbert 공간에 대한 내적에 대한 더 일반적인 표기법이라는 데 동의합니다. 그것들은 제가 일반적으로 사용하는 표기법입니다. 유니코드 대괄호를 함수/매크로 호출로 구문 분석하는 것에 대한 논의가 있었습니다(예: #8934 및 #8892). 그러나 아무데도 가지 않았으며 이것은 곧 변경될 것 같지 않습니다.)

@stevengj , 이 단락을 이전 주석에 직접 추가했을 때 ⟨u,v⟩ 구문을 언어에서 구현하기 어렵다는 의미입니까?

이 기능이 Julia v1.0에 포함될 가능성이 있습니까? 나는 일반적인 내부 제품의 개념에 의존하는 많은 아이디어와 패키지를 가지고 있습니다. 내 기대치를 낮춰야 하는지 알려주세요. 지속적인 알림 죄송합니다.

#27401 못봤어?

@jebej 감사합니다 그리고 앞장서주신 @ranocha 감사합니다 :heart:

이 단락을 이전 주석에 직접 추가했을 때 ⟨u,v⟩ 구문이 언어에서 구현하기 어렵다는 것을 의미합니까?

파서에 추가하는 것이 기술적으로 어렵지는 않지만 언어에서 사용자 지정 괄호를 나타내는 방법(및 여부)에 대한 합의를 도출하는 것이 어려운 것으로 입증되었습니다. #8934에서 토론을 참조하십시오. 이 토론은 4년 전 아무데도 없었고 그 이후로 부활하지 않았습니다. (다른 분야에서 사람들이 많은 다른 것에 대해 동일한 대괄호를 사용한다는 사실에 추가합니다. 예를 들어 ⟨u⟩는 통계 물리학의 앙상블 평균에 사용됩니다.) #8892에서 제기된 또 다른 문제는 다양한 유니코드의 시각적 유사성입니다. 괄호.

@stevengj 감사합니다. 설명에 감사드립니다. 패키지 전반에 걸쳐 표준화된 일반 내부 제품을 갖게 되어 매우 기쁩니다. :100: 꺾쇠 괄호 표기법은 향후 다른 릴리스 주기에서 빛날 수 있습니다. 중요하지는 않지만 우리 출판물에 있는 수학처럼 문자 그대로 코드를 작성할 수 있다는 것은 매우 편리합니다.

⟨args...⟩ 가 anglebrackets 연산자를 호출하기 위한 유효한 구문인 경우(이 구문에서 호출하는 함수를 호출하는 것은 실제로 전례가 없기 때문에 다소 까다롭습니다), 사람들은 다음과 같이 할 수 있습니다. 구문에 대해 원하는 의미를 선택하십시오.

@StefanKarpinski , #8934의 주장은 매크로여야 한다는 것이었습니다. 나는 우리가 합의에 도달했다고 생각하지 않습니다.

(Base에서 anglebrackets(a,b) 가 inner(a,b) 를 의미한다고 결정하면 이미 결정이 내려졌기 때문에 사람들이 "원하는 의미로 선택"하는 것을 방해할 것입니다.
물론 끔찍한 선택은 아니지만 구문 분석되는 한 Base에서 이 의미를 할당할 필요가 없을 수도 있습니다.)

나는 그 토론의 세부 사항을 기억하지 못하지만 매크로를 만드는 것은 분명히 나에게 나쁜 생각처럼 보입니다.

#27401 이너 제품을 진지하게 생각하고 있다고 생각할 수 있습니다.

전통적으로 이슈는 관련 PR이 병합될 때만 닫힙니다...

물론, 우리는 그것을 열어 둘 수 있습니다. 분류 레이블에서 없애고 싶었을 뿐입니다.

#27401이 지금 병합되었으므로 닫혀야 합니까?