Numpy: 타원을 사용한 인덱싱 동작은 직관적이지 않습니다.

이것은 특히 불쾌한 코너 케이스처럼 보입니다. ... 는 두 가지 고급 인덱스 인 0 및 [0] 를 인접하지 않은 것으로 간주하도록 강요하는 것으로 간주합니다. 인접한 _are_를 인덱싱하는 축.

numpy 인덱싱을 복제하려고 할 때이 문제가 발생했습니다. 나는 이것이 두 가지 규칙 사이의 이상한 상호 작용이라고 생각합니다.

• 줄임표는 각각 기본 인덱스로 간주되는 전체 슬라이스의 튜플로 확장됩니다.
• 혼합 순서 고급 및 기본 인덱스는 전치 작업을 트리거합니다.

이 특별한 경우는 0-d 튜플 (...이 모든 인덱스와 함께 사용될 때)이 실제로 보이지 않아야 할 때 여전히 기본 인덱스 블록으로 간주되기 때문에 트리거됩니다.

나는 이것이 모두 혼란스럽고 여기서 무슨 일이 일어나는지 확인하지 않고는 확신조차 못했을 것이라는 데 동의합니다. 그러나 그것은 나에게 올바른 선택처럼 보입니다.

진정으로 "보이지 않는"이유는 무엇입니까? ... 는 모든 차원에 대해 동일하게 작동해야합니다. 그렇게하려면 모든 경우에 조옮김을 트리거해야합니다. 예를 들어 series, ..., color 로 구성되어 있으며 ... 는 사용자가 정의하고 0-d 일 수 있습니다. 해당 데이터를 처리하는 프로그램을 작성하려면 ... 확장 (또는 확장하지 않음)에 상관없이 인덱싱이 예측 가능하게 전치되어야합니다.

결국 이것은 혼란스럽고 우리는 .oindex 및 .vindex 등을 더 심각하게 선택해야합니다. https://numpy.org/neps/nep- 0021-advanced-indexing.html

나는 현재 행동이 최고의 일반화라는 @seberg 의 주장을 가지고 있습니다. 그래도 문서가 더 명확하다는 것을 확실히 확인할 수 있습니다.

나는 그 제안에 대해 몰랐습니다. @seberg 참조에 감사드립니다!

내가 당신의 주장을 이해할 수 있도록 다시 말하겠습니다. 고급 인덱스 A 및 기본 인덱스 B 레이블을 지정하고 위와 같이 재정렬 op a (일반화) 전치라고합니다. 귀하의 예에는 네 가지 경우가 있습니다.

• [A1, ..., A2] 및 [B1, ... A1] : 이러한 경우 ... 확장 방법에 관계없이 [A1, A2, ....] 및 [A1, B1, ...] 전치가 트리거됩니다.
• [A1, ..., B1] 및 [B1, ..., B2] :이 경우는 그렇지 않습니다.

이러한 규칙은 ... 확장 방식에 관계없이 series 및 color 클래스 (A 또는 B)가 어떤 클래스에 속하는지 알면 일관성이 있습니다. 이것은 ... 를 (잠재적으로 0-d) 기본 인덱스 블록으로 취급하는 것과 같습니다. 0-d ... 를 특수한 경우로 취급하는 것은 사용자가 2D 배열을 전달했는지 3D 이상을 전달했는지에 따라 전치가 조건부이기 때문에 나쁠 것입니다. 동의합니다. 이곳은 안 좋은 곳입니다.

0-d 블록이 작동하지 않아야한다는 내 직감은 튜플이 어떻게 작동하는지, i ,

i: int
M: Tuple[int, ...]
N = ()
assert M[:i] + N + M[i:] == M

이는 i 가 무엇인지에 따라 위의 네 가지 경우가 발생하는 numpy 인덱싱 규칙과 충돌합니다. 이것은 ... 가 처리되는 방식보다는 전치 연산 자체와 더 관련이 있으며 NEP21 제안에 대한 논쟁입니다.

개발 중에 우리는 인덱싱 방법을 전환하고 ... 를 삽입하여 코드를 미래에 대비하고 모양이 마술처럼 바뀔 때 정말 혼란 스러웠습니다. 빈 ... 케이스가 특히 반 직관적이어서 악화되었습니다.

봐 주셔서 감사합니다! 원하시면 문서 PR을 제출할 수 있습니다.

@antonl a doc PR은 항상 환영합니다. 여기에서 많은 개선이 가능합니다.