Numpy: ENH: 'axis' 인수가 있는 'random.shuffle'의 대안입니다.

이것이 대안이 필요한 이유를 알지 못합니다.
셔플 축 인수? 기본값은 np.sum과 같이 None입니다.

2014년 10월 11일 토요일 오후 9시 36분, Warren Weckesser [email protected]
썼다:

numpy.random.shuffle에 대한 대안이 있으면 좋을 것입니다.
축 인수를 받아들이고 독립적으로 셔플합니다.
1차원 조각. 여기 내가 disarrange라고 부를 구현이 있습니다.
작동하지만 더 효율적인 C 구현이 있으면 좋을 것입니다.

def disarrange(a, axis=-1):
""
주어진 축을 따라 제자리에서 a 를 섞습니다.

Apply numpy.random.shuffle to the given axis of `a`.
Each one-dimensional slice is shuffled independently.
"""
b = a.swapaxes(axis, -1)
# Shuffle `b` in-place along the last axis.  `b` is a view of `a`,
# so `a` is shuffled in place, too.
shp = b.shape[:-1]
for ndx in np.ndindex(shp):
    np.random.shuffle(b[ndx])
return

예시:

[156]에서: a = np.arange(20).reshape(4,5)

[157]에서:
아웃[157]:
배열([[ 0, 1, 2, 3, 4],
[ 5, 6, 7, 8, 9],
[10, 11, 12, 13, 14],
[15, 16, 17, 18, 19]])

[158]에서: disarrange(a, axis=-1)

[159]에서:
아웃[159]:
배열([[ 2, 0, 4, 3, 1],
[ 8, 6, 7, 9, 5],
[11, 14, 13, 10, 12],
[19, 18, 16, 17, 15]])

[160]에서: a = np.arange(20).reshape(4,5)

[161]에서: disarrange(a, axis=0)

[162]에서:
아웃[162]:
배열([[ 5, 11, 7, 13, 14],
[ 0, 6, 2, 3, 4],
[10, 1, 17, 18, 19],
[15, 16, 12, 8, 9]])

이 요청은 stackoverflow에 대한 다음 질문에 의해 동기가 부여되었습니다.
http://stackoverflow.com/questions/26310346/quickly-calculate-randomized-3d-numpy-array-from-2d-numpy-array/

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5173.

나다니엘 J. 스미스
박사후 연구원 - 정보학 - University of Edinburgh
http://vorpus.org

shuffle 의 현재 동작은 실제로 axis=None . 인수를 1차원 시퀀스로 취급합니다.

In [181]: a = np.arange(20).reshape(4,5)

In [182]: np.random.shuffle(a)

In [183]: a
Out[183]: 
array([[ 0,  1,  2,  3,  4],
       [15, 16, 17, 18, 19],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14]])

axis=0 로 해석할 수 있지만 누락된 기능은 1D 슬라이스의 독립적인 셔플링입니다.

2차원 배열의 경우 a.T 를 섞어서 axis=1 를 에뮬레이트할 수 있지만 이렇게 하면 독립적인 셔플링을 얻을 수 없습니다.

In [184]: a = np.arange(20).reshape(4,5)

In [185]: np.random.shuffle(a.T)

In [186]: a
Out[186]: 
array([[ 4,  1,  0,  3,  2],
       [ 9,  6,  5,  8,  7],
       [14, 11, 10, 13, 12],
       [19, 16, 15, 18, 17]])

disarrange 에서 axis=None 가 np.random.shuffle(a.flat) 처럼 작동할 것으로 예상합니다.

동작 방식을 제어하는 ​​적절한 인수를 shuffle 에 추가하여 대체 셔플링을 구현하면 괜찮겠지만 해당 API에 대한 제안이 없습니다.

shuffle axis 및 independent (또는 해당 행에 따라)의 두 인수를 추가할 수 있습니다. 새 서명은 다음과 같습니다.

def shuffle(a, independent=False, axis=0)

independent 이 False 이면 현재 shuffle 처럼 작동합니다. True이면 disarrange 처럼 작동합니다.

오, uh, 나는 그것이 유사한 것과 더 일치한다고 가정했습니다.
sort :-(와 같은 기능을 합니다. 이런 종류의
shuffling-of-slice는 idx = arange(...)와 같이 작성되었습니다. 셔플(idx);
multi_dim_array[idx, ...]; 그러나 아무도 나에게 묻지 않았습니다 :-)

일치하는 호출 규칙이 있는 셔플 버전에서 +1입니다.
np.sort, 하지만 일반적으로 목록을 확인해야 합니다. 그들은 가질 수 있습니다
최고의 이름과 같은 중요한 문제에 대한 제안도 :-)

(아마도 "스크램블"?)

2014년 10월 11일 토요일 오후 10시 31분, Warren Weckesser < 알림 @github.com

썼다:

셔플의 현재 동작은 실제로 axis=None과 같지 않습니다. 취급한다
1차원 시퀀스로서의 인수.

[181]에서: a = np.arange(20).reshape(4,5)

[182]에서: np.random.shuffle(a)

[183]에서:
아웃[183]:
배열([[ 0, 1, 2, 3, 4],
[15, 16, 17, 18, 19],
[ 5, 6, 7, 8, 9],
[10, 11, 12, 13, 14]])

축=0인 것으로 해석할 수 있지만 누락된 기능은
1차원 슬라이스의 독립적인 셔플링.

2차원 배열의 경우 aT를 섞어서 axis=1을 에뮬레이트할 수 있지만 이것은
당신에게 독립적인 셔플을 얻으십시오:

[184]에서: a = np.arange(20).reshape(4,5)

[185]에서: np.random.shuffle(aT)

[186]에서:
아웃[186]:
배열([[ 4, 1, 0, 3, 2],
[ 9, 6, 5, 8, 7],
[14, 11, 10, 13, 12],
[19, 16, 15, 18, 17]])

정리하지 않으면 axis=None이 다음과 같이 작동할 것으로 예상됩니다.
np.random.shuffle(a.flat).

다음을 추가하여 대체 셔플링을 구현하면 괜찮을 것입니다.
작동 방식을 제어하는 ​​셔플에 적절한 인수가 있지만
해당 API에 대한 제안이 있습니다.

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

나다니엘 J. 스미스
박사후 연구원 - 정보학 - University of Edinburgh
http://vorpus.org

아, 원하는 동작을 sort 의 유사체로 설명하는 것은 좋은 생각입니다.

오, 어, 나는 그것이 sort와 같은 유사한 기능과 더 일관성이 있다고 가정했습니다.

나도 놀랐고, stackoverflow 질문에 대한 의견을 바탕으로 적어도 두 명의 다른 경험 많은 numpy 사용자가 놀랐습니다. 메일링 리스트에 대한 토론을 시작하겠습니다.

일반 사용자가 현재 잘못 알고 있다면 가치가 있다고 생각합니다.
다른 옵션 언급 -- 우리는 다음 중에서 선택할 인수를 _할 수 있습니다_
현재 동작으로 기본 설정을 시작하는 두 가지 동작,
그리고 어떤 시점에서 많은 FutureWarning과 고함 후에 기본값을 전환하십시오.
사람들에게 경고하기 위해. 그러나 그것은 추악한 전환입니다 ...

2014년 10월 11일 토요일 오후 11:00 Warren Weckesser < [email protected]

썼다:

오, uh, 나는 그것이 유사한 것과 더 일치한다고 가정했습니다.
정렬과 같은 기능

저도 놀랐고, stackoverflow에 대한 댓글을 바탕으로
질문, 적어도 두 명의 다른 경험 많은 numpy 사용자가 놀랐습니다. 아픈
메일링 리스트에 대한 토론을 시작하십시오.

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

나다니엘 J. 스미스
박사후 연구원 - 정보학 - University of Edinburgh
http://vorpus.org

그들은 최고의 이름과 같은 중요한 문제에 대한 제안을 할 수도 있습니다.

Sue라는 함수가 필요합니다.

sort(axis=N)과 유사하게 이 기능이 존재할 것으로 예상했기 때문에 이 기능을 +1하고 싶었습니다. 메일링 리스트에 대한 결정이 있었나요?

메일링 리스트 스레드는 다음과 같습니다.
http://thread.gmane.org/gmane.comp.python.numeric.general/59014

이것은 정말 유용할 것입니다!

나는 또한 그것을 감사합니다!

https://stackoverflow.com/a/35647011/3401634 에 따르면 다차원 배열의 경우 X

np.random.shuffle(X)

와 같다

np.take(X, np.random.permutation(X.shape[0]), axis=0, out=X)

그래서 구현하지 않는 이유

np.random.shuffle(X, axis=axis)

~처럼

np.take(X, np.random.permutation(X.shape[axis]), axis=axis, out=X)

기본 axis=0 ?

이것에 대한 소식이 있습니까? 이 기능이 존재하지 않는다는 것에 놀랐습니다. 지금은 해결 방법으로 np.random.permutation 와 함께 np.apply_along_axis 사용하고 있습니다.

#13829 때문에 지금 닫을 수 있습니까?

(여기서 예제를 작업하는 동안 새 셔플 코드에서 버그를 발견했습니다. 다음 내용에서는 https://github.com/numpy/numpy/pull/14662에서 제안된 수정 사항을 사용하고 있습니다. 병합되었습니다.)

@wkschwartz , #13829의 변경 사항은 유용하지만 여기서 요청한 개선 사항은 아닙니다. #13829에 추가된 축은 여전히 ​​배열을 섞을 1차원 시퀀스로 취급합니다. 새 axis 인수를 사용하면 사용자가 1차원 축으로 표시되는 축을 지정할 수 있지만 축 내에서 독립적인 셔플을 수행하지 않습니다.

예를 들어,

In [1]: import numpy as np                                                      

In [2]: rng = np.random.default_rng()                                           

In [3]: x = np.arange(20).reshape(2, 10)                                        

In [4]: x                                                                       
Out[4]: 
array([[ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14, 15, 16, 17, 18, 19]])

In [5]: rng.shuffle(x, axis=1)                                                  

In [6]: x                                                                       
Out[6]: 
array([[ 5,  9,  6,  4,  7,  0,  3,  2,  1,  8],
       [15, 19, 16, 14, 17, 10, 13, 12, 11, 18]])

행이 독립적으로 섞이지 않은 것을 볼 수 있습니다. 열이 재배열되었지만 각 열 내의 값은 동일합니다.

이 문제에서 요청된 동작은 위에서 제공한 disarrange 코드에서와 같이 독립적으로 셔플하는 것입니다.

In [10]: x = np.arange(20).reshape(2, 10)                                       

In [11]: x                                                                      
Out[11]: 
array([[ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14, 15, 16, 17, 18, 19]])

In [12]: disarrange(x, axis=1)                                                  

In [13]: x                                                                      
Out[13]: 
array([[ 4,  3,  7,  8,  0,  6,  5,  2,  9,  1],
       [12, 15, 19, 17, 18, 14, 10, 13, 11, 16]])

나는 이것을 다시 띄우고 싶습니다. 아마도 수요일 회의를 위해서도 마찬가지일 것입니다. 우리는 더 높은 차원의 기능을 추가 choice 및 permutation 와 1.18도 축 인수를 (이것은 새로운 따라서이다).

이들 모두는 현재의 임의 로직 사용 shuffle the subarrays along this axis 대신에, shuffle along (individual) axis 내가 어떻게해야하는지 틀림없이 생각합니다. 즉, "따라서" 또는 주어진 축 내에서 "위에서" 섞습니다.

그러나 거의 모든 경우에 axis 는 이름에 "over"가 있는 apply_over_axes 와 같이 거의 예외를 제외하고 NumPy에서 축을 따라를 의미합니다. 그래서 나는 대담하게 논쟁의 이름을 over_axis=0 바꾸는 것이 혼란을 피하는 것이 더 낫다고 주장할 것입니다! 특히 잘못된 셔플링을 알아차리기 어려울 수 있는 난수의 경우.

위의 github 상호 참조에서 언급했듯이 https://github.com/numpy/numpy/pull/15121에 진행 중인 PR이

더 시급히에 대해 우려 내가 개인적으로 나는 멋진 @WarrenWeckesser, 우리는 그에서 최근 새로운 API의 의미와 위로를 확장한다는 것이다.
그리고 적어도 axis 인수의 이름을 변경하여 부분적으로 되돌려서는 안 되는지 궁금합니다. 아니면 잠시 동안 다시 다차원적 행동을 완전히 없애버리거나...

제가 지금 너무 과민반응을 하고 있는건지도 모르겠습니다. 예전에 이걸 놓치거나 끝까지 생각하지 못한게 조금 짜증이 나네요... 하지만 솔직히 현재의 논리는 매우 위험하다고 생각합니다. 기대에 부응 하는 의미를 제공하지 못한다는 사실을 놓치기 쉽습니다. 그리고 np.sort 사용하는 의미가 아닙니다.

@seberg , 이 문제를 axis 의 두 가지 해석에 대해 "over" 및 "along"을 사용하는 규칙을 따를 것입니다. 이 시점에서 shuffle 및 permutation 대한 shuffle axis 의 기존 "동행" 해석을 ​​완전히 취소할 수 있는지 모르겠지만 많은 사람들이 우리가 할 수 있다는 것이 밝혀지면 기쁠 것입니다. :)

몇 년 전 메일링 리스트 토론의 끝에서 나는 해결책이 shuffle 및 permutation 의 API를 변경 하지 않고 대신 축을 따라 무작위화된 두 가지 새로운 메소드를 도입하는 것이라고 생각하게 되었습니다. 대신에. 한 방법은 제자리에서 작동하고 다른 방법은 복사본을 반환합니다. 당시 내가 선호하는 이름은 permute 와 permuted 였지만, 그 이름에 대해 약간의 반대가 있었습니다. 작년 12월의 PR에서 나는 그것들을 randomly_permute 및 randomly_permuted 라고 불렀지만 그 이름은 자리 표시자로 간주되어야 합니다. 이러한 이름을 결정하기 전에 두 개의 새 기능을 추가하는 것이 올바른 접근 방식인지 결정해야 합니다. 여기서부터는 간결함을 위해 제안된 새로운 방법을 permute 및 permuted 로 지칭하겠습니다.

새 함수를 사용하면 다음과 같은 관련 Generator 메서드가 있습니다.

meaning    operate     return
of axis    in-place     copy
-------    --------  -----------
"over"     shuffle   permutation
"along"    permute   permuted

(축 "위에서" 작동하는 메서드 shuffle 및 permutation 가 이미 존재합니다.)

두 가지 새로운 방법 대신 내부 대 복사 동작을 제어하는 ​​매개 변수가 있는 하나만 사용하는 것이 좋습니다. 이에 대한 두 가지 제안이 떠올랐습니다.

(a) out 매개변수를 추가합니다. 제자리에서 작업하려면 입력 배열을 out 로 전달하십시오. out 가 제공되지 않으면 셔플된 복사본을 반환합니다.
(b) 원하는 동작을 지정하는 copy 또는 inplace 와 같은 부울 플래그를 추가합니다.

새 메서드를 만드는 주요 대안은 axis 해석 방식을 변경하는 새 매개변수를 기존 메서드에 추가하는 것입니다. 이를 나열하기 전에 추가 인수가 실제로 어떻게 사용될 수 있는지에 대해 메일링 리스트 스레드에서 Robert Kern이 작성한 의견을 반복하겠습니다(여기에서 아래 표시된 independent 매개변수 참조).

대신에 두 가지 방법을 사용하는 것이 완벽하게 좋은 이유인 것 같습니다.
하나. 리터럴 True 또는 False를 사용하지 않을 때를 상상할 수 없습니다.
이를 위해서는 실제로 두 가지 다른 방법이어야합니다.

( 사설 탈주 : 이런 논의에서 불가피하게 네임스페이스(이 경우 Generator 네임스페이스)를 늘리는 문제가 발생합니다(때로는 "네임스페이스 오염"이라고 함). 네, 모두 동의합시다. 모든 것이 같으면 더 작은 네임스페이스가 더 좋습니다. 그러나 대부분의 API 설계 결정과 마찬가지로 고려해야 할 절충안이 있습니다. 네임스페이스를 더 작게 유지하되 어색하거나 지나치게 복잡한 API를 사용하여 메소드를 생성하면 승리하지 못합니다.)

이 모든 것을 말하면서 제안된 shuffle 의 기존 서명에 두 가지 추가 사항이 있습니다.

(1) shuffle(x, axis=0, independent=False) : 부울 플래그 independent 는 axis 가 해석되는 방식을 결정합니다: False -> "over", True -> "along". ( independent 보다 더 나은 이름이 있을 수 있습니다.)
(2) shuffle(x, axis=0, iaxis=???) : 두 번째 인수 iaxis 는 "동행" 동작에 대한 축을 제공합니다. ( axis 와 상호 작용하는 방법은 명확한 사양이 필요합니다. iaxis 값을 지정하면 axis 가 무시됩니다.)

저는 지금까지 나온 다양한 API 아이디어를 모두 다뤘다고 생각합니다. 다른 사람을 아는 사람이 있으면 알려주십시오.

여기에서 API를 늘리는 데 만족합니다. 나는 그것에 반대해야 할 많은 이유가 있는지 확신하지 못합니다.

• 유용하다는 데 동의할 수 있습니다.
• 기존 기능으로 달성할 수 있는 좋은 방법이 없습니다.
• 전체 동작 전환에 kwarg 를 사용하는 것은 정상적인 패턴이 아닌 것 같습니다. 저는 Rober Kern이 완전히 거기에 있었다고 생각합니다.

여기서 진행 중인 일은 shuffle 및 permutation (아마도 choice )를 인덱싱 작업(예: take )과 비교할 수 있다는 것입니다. axis 대해 동일한 의미를 사용합니다. 그리고 그것은 나에게 이상한 조금 느끼는 이유는, 그것도 당신이 사용하는 경우 그 자체가하는 색인 (일반 배열 인식 기능과는 달리 ND에 일반화 할 수 없다는이 정의의 단점 아마도 arr[..., index] . 그게 다입니다 배열 스택으로 일반화하고 각 개별 배열에 대해 이전과 동일한 작업을 수행).
take_along_axis 는 take 가 ND로 올바르게 (복잡해 보일지라도) ND 일반화 가능한 "함께" 의미를 제공합니다. apply_along_axis 및 apply_over_axis 는 "over"가 올바른 단어인지 확실하지 않지만 "over"를 가져온 곳입니다...

permutation (쉽게 변경할 수 없지만 shuffled 이어야 함)이 여기서 실제 이상값임을 알았습니다. shuffle - shuffled , permute - permuted 그러면 상황이 꽤 명확하고 합리적으로 보이기 시작합니다. shuffled 를 추가하고 permutation 에 대한 지원 중단을 시작하려는 사람이 있습니까? permutation 도 itertools.permutations , FWIW에서 동작이 매우 일관적이지 않습니다.

나는 permutation , permute , permuted 가 서로 다른 행동을 가진 유사하게 들리는 이름의 혼란스러운 세 겹이라고 생각합니다. 이것을 피하는 것이 좋습니다(장기적으로 가능).

기존 API를 확장하는 것은 간단해 보이지만, 동작을 근본적으로 바꾸는 키워드가 없다는 @rkern 의 포인트가 최선의 길이라고 생각합니다.

제자리 대 제자리 아님의 경우 NumPy에 대체 out= 철자가 있다고 가정합니다. 그러나 shuffle이 제자리에 있기 때문에 솔루션이 아니며 shuffled가 좋습니다. permuted 대한 것일 수 있습니다(예: permuted(arr, out=arr) 는 permute(arr) 와 동일하지만 셔플과 달리 ndarray 로 변환됨).
어떤 경우에는, I 비하의 계획처럼 permutation 찬성 shuffled 새로운 네임 스페이스를 정리하기!

이 문제(및 https://github.com/numpy/numpy/pull/15121의 관련 PR)로 돌아갑니다.

원래 문제를 만들고 현재 shuffle API의 문제를 설명하려고 할 때 문제를 설명하는 한 가지 방법은 대부분의 사람들이 axis 인수를 예상한다는 것입니다. shuffle 중 sort 의 axis 인수와 동일하게 작동합니다. sort 와의 비유는 꽤 좋으므로 정렬을 위한 복사와 제자리 작업의 문제를 처리하는 방법을 살펴보는 것도 유용할 수 있습니다. numpy.sort() 함수는 배열과 유사한 인수를 허용하고 정렬된 복사본을 반환합니다. 내부 정렬의 경우 ndarray sort() 메서드를 사용 합니다. 기존 ndarray에 대한 메소드이기 때문에 in-place 작업이 명확합니다. gh-15121에서 인수를 무작위로 바꾸는 in-place 함수의 인수 는 ndarray np.array 가 수행하는 모든 모양 검색을 수행해야 하고 변경할 수 없는 것으로 판명된 입력도 거부해야 합니다(예: [(1, 2, 3, 4), (5, 6, 7, 8)] 의 제자리 셔플을 수행할 수 없습니다. ).

셔플된 복사본을 반환하는 함수 와 제자리에서 셔플하는 ndarray 메서드 를 사용하여 sort API를 실제로 복제할 수 있다면 좋겠지만 그런 추가는 생각하지 않습니다. ndarray 클래스에 대한 메소드는 승인될 가능성이 있습니다.

그리고 제자리에서 섞이는 ndarray _method_ 하지만 ndarray 클래스에 이러한 메서드를 추가하는 것이 승인될 가능성은 없다고 생각합니다.

싱글톤 생성기가 없으면 달성할 수 없다고 생각합니다.

@bashtage가 썼다

permutation (쉽게 변경할 수 없지만 shuffled 이어야 함)이 여기서 실제 이상값임을 알았습니다. [만약] shuffle-shuffled , permute-permuted 그러면 상황이 꽤 명확하고 합리적으로 보이기 시작한다고 생각합니다. shuffled 를 추가하고 permutation 에 대한 지원 중단을 시작하려는 사람이 있습니까?

이것은 메일링 리스트 토론(일종의)이 2014년에 수렴된 것입니다. 다음은 Nathaniels 제안에 대한 링크입니다. https://mail.python.org/pipermail/numpy-discussion/2014-October/071364.html

그의 scramble[d] 는 내가 https://github.com/numpy/numpy/pull/15121 에서 randomly_permute[d] 라고 불렀던 것 입니다.

permutation 대신 shuffled 를 추가하고 축을 따라 작동하는 새 메서드를 호출하면 permute[d] 관련 함수 테이블은 다음과 같습니다.

meaning    operate
of axis    in-place   return copy
-------    ---------  -----------
"over"     shuffle    shuffled
"along"    permute    permuted

일관성이 좋습니다. 이 API 버전에서는 어떤 메서드에도 out 매개변수가 없습니다.

https://github.com/numpy/numpy/pull/15121 에서 최근에 out 인수가 어떻게 될 수 있는지 보여주는 보기 흉하고 명백한 임시 이름 permuted_with_out 을 사용하여 다른 메서드를 추가했습니다. 사용 된. out 매개변수를 사용하고 기존 메소드 shuffle 및 permutation 을 그대로 사용하면 테이블은 다음과 같습니다.

meaning    operate
of axis    in-place                           return copy
-------    ---------------------------------  --------------------
"over"     shuffle(x, axis)                   permutation(x, axis)
"along"    permuted_with_out(x, axis, out=x)  permuted_with_out(x, axis)

그러나 out 매개변수를 도입하려는 경우 일관성이 있어야 하며 permutation 에서도 사용해야 합니다. 그리고 permutation 를 shuffled 바꾸는 것을 고려할 수 있습니다. 그리고 새로운 shuffled 메소드에는 제자리 연산을 허용하는 out 매개변수가 있으므로 shuffle 는 중복되어 permutation 와 함께 사용되지 않을 수 있습니다. 그런 다음 shuffled 및 permuted 의 "좋은" 이름으로 전환하면 테이블은 다음과 같습니다.

    meaning    operate
    of axis    in-place                  return copy
    -------    ------------------------  -----------------
    "over"     shuffled(x, axis, out=x)  shuffled(x, axis)
    "along"    permuted(x, axis, out=x)  permuted(x, axis)

out 매개변수는 제자리에서 작동하기 위한 것만이 아닙니다. 이를 통해 출력 배열을 재사용할 수 있으므로 잠재적으로 임시 배열 생성을 피할 수 있습니다. 이것은 shuffle/shuffled/permute/permuted API에 비해 이 API의 장점이지만 그 장점이 실제로 얼마나 중요한지 잘 모르겠습니다. 이 API의 단점은 shuffle 및 permutation 의 두 가지 방법이 더 이상 사용되지 않는다는 것입니다. 이는 즉각적인 영향을 줄이기 위해 잠시 동안 "부드러운" 사용 중단이 될 수 있습니다(즉, 문서에서 사용을 강조하지 않지만 실제로 사용 중단 경고를 잠시 추가하지 않음).

이것이 변화에 대한 두 가지 주요 경쟁자에 대한 요약입니다. 우리는이 shuffle/shuffled/permute/permuted 버전 또는 함께 버전 shuffled/permuted 와 out 매개 변수를. 2014년에 누군가가 논의된 변경 사항을 구현하기 위해 뛰어들었다면 아마도 shuffle/shuffled/permute/permuted 버전이 이미 있을 것입니다. 그러나 out 사용하는 버전에는 몇 가지(작은? 사소한?) 이점이 있습니다. 이름이 4개가 아닌 2개이고 out 사용하면 잠재적으로 사용자가 더 적은 임시 변수를 가질 수 있습니다. 나는 둘 중 하나에 만족할 것입니다.

사람들은 어떻게 생각합니까?

귀하가 나열한 세 가지 시나리오 중 순서대로 1, 3, 2에 훨씬 못 미치는 순위를 지정하겠습니다. 매우 근본적으로 다른 일을 하는 2개의 순열은 큰 혼란의 원인으로 보입니다. 내 개인적인 취향은 기능에 액세스하기 위해 out을 의무적으로 사용하는 것을 피하는 것입니다. 나는 항상 out을 일부 시나리오에서 의미가 있을 수 있는 성능 선택으로 생각합니다. 저는 학생들에게 단지 기능에 액세스하기 위해 사용하도록 가르치고 싶지 않습니다. 또한 3 x = shuffled(x, axis, out=x) 가 return x 아닌 return None 가 있는 동안 x 끝날 수 있다고 가정합니다. 3번 등장.

내 개인적인 취향은 기능에 액세스하기 위해 out을 의무적으로 사용하는 것을 피하는 것입니다. 나는 항상 out을 일부 시나리오에서 의미가 있을 수 있는 성능 선택으로 생각합니다.

그러나 제자리에서 셔플하는 것은 _성능 선택입니다, 그렇죠?

그러나 제자리에서 셔플하는 것은 _성능 선택입니다, 그렇죠?

사용 가능한 경우 제자리에서 코딩 스타일을 선택할 수도 있습니다. 아마도 혼란스럽고 오류가 발생하기 쉬운 것입니다.

내 개인적인 견해는 f(x, out=x)가 때때로 무언가를 빠르게 달성하기 위해 매우 명확하지 않은 방법으로 사용되기 때문에 항상 약간 마법처럼 느껴진다는 것입니다. f(x, inplace=True)는 다른 것처럼 보이지는 않지만 훨씬 더 명확해 보입니다(대부분 제거된 오래된 판다 패턴처럼 보입니다).

사실이지만 NumPy에서 일반적으로 out=... 사용하는 것처럼 보이는 코딩 스타일 선택입니다(내부 연산자 또는 메서드를 사용하지 않는 한). 아니면 NumPy가 현재 대부분의 경우 쉽게 하려고 하지 않는 코딩 스타일 선택일 수도 있습니다.

나는 그것이 약간 마술적이라는 것을 인정하고 inplace= kwarg는 덜 마술적일 수 있지만 실제 우선 순위가 없을 수도 있습니다. 그리고 그것이 덜 마법처럼 보이는 주된 이유는 내부 셔플이 여기에서 알고리즘의 핵심에 있기 때문인지 확실하지 않습니다. 알고리즘 세부 사항은 대부분의 학생들에게 그다지 중요하지 않아야 하며 결국 out= 를 사용하는 것은 대략 단일 사본 + 관련 메모리 대역폭을 보호하며 ufuncs와 비슷합니다. (ufuncs out=input 경우에도 충분히 공정하지만, 고급 사용자를 위한 일반적인 마법이자 알려진 패턴입니다.)

작성하기가 약간 지루하고 읽기가 다소 빠르지 않지만 np.shuffled(x, out=x) 동작이 무엇인지에 대해서는 매우 명확해 보입니다. 불분명한 부분은 성능에 미치는 영향만 있는 것으로 보이며, 이는 고급 사용자가 걱정해야 할 문제로 보입니다.

out 사용을 옹호하는 사람들을 위한 가상의 질문: 기존 함수 numpy.sort 및 ndarray.sort 가 없고 지금 정렬 기능을 추가하고 있다면 선호하는 API는 numpy.sorted(a, axis=-1, kind=None, order=None, out=None) (내부 정렬을 위해 ndarray.sort 메서드를 구현할 필요 없음)?

ndarray.sort 는 list.sort 모델로 하므로 상관없이 합리적인 API 선택일 것입니다. 즉, 나는 np.sort 가 존재하지 않고 대신 np.sorted(..., out=...) 를 선호했을 것입니다.

예, np.sort 이름은 np.sorted 로 지정해야 한다고 생각합니다(파이썬의 sorted() 마찬가지로). 메서드에만 제자리 동작이 있기 때문에 크게 우려하지는 않습니다.

" ndarray.sort 메서드를 구현할 필요가 없음"에 대해 잘 모르겠습니다. 메서드(또는 제자리 동작)에 문제가 있는 것은 아닙니다. 방법에 대한 질문은 우리가 편리한 방법을 속기적으로 제공하는 것이 충분히 중요하다고 느끼는지 여부입니다.
제자리 기능 버전을 갖는 것에도 문제가 없다고 생각합니다. 제자리에 없는 버전은 새로운 사용자에게 더 좋은 것처럼 보이고 고급 사용자에게 충분히 잘 제공될 만큼 일반적인 out= 패턴입니다.

"ndarray.sort 메서드를 구현할 필요가 없음"에 대해 잘 모르겠습니다. 메서드(또는 제자리 동작)에 문제가 있는 것은 아닙니다.

그것은 내 API 사고 실험의 일부였습니다. 나는 우리가 지금 가지고 있는 것에 문제가 있다는 것을 암시하려는 것이 아닙니다. 나는 단지 우리가 처음부터 시작했다면-그리고 목록에 대해 Python API를 일치시키는 것과 관련이 없다는 가정적인 전제를 추가할 것입니다--그러면 정렬에 선호되는 API는 numpy.sorted(..., out=...) 이 될 것입니다

또 다른 질문, 그래서 가상하지 : 사용하는 경우 out NumPy와 전역 API의 일관성을 위해, 다음, 여기에 기본 옵션입니다, 우리가 결국 추가 계획을 세워야 out 에 numpy.sort , numpy.partition , numpy.argsort , 그리고 현재 가지고 있지 않은 다른 모든 것 ?

예, 제 생각에는 ufuncs와 동일한 의미로 out= kwarg를 추가하는 것이 거의 모든 NumPy API 기능에 좋은 선택입니다. out 인수가 부족하면 일반적으로 개선되기를 기다리고 있습니다(하지만 실제로는 약간의 개선일 수 있으며 드문 경우에는 코드 복잡성을 너무 많이 추가할 가치가 없을 수도 있습니다).