Numpy: 오리 배열 강제 지원

제안 된 구현은 다음과 같습니다.

import numpy as np

# hypothetical np.duckarray() function
def duckarray(array_like):
  if hasattr(array_like, '__duckarray__'):
    # return an object that can be substituted for np.ndarray
    return array_like.__duckarray__()
  return np.asarray(array_like)

사용 예 :

class SparseArray:
  def __duckarray__(self):
    return self
  def __array__(self):
    raise TypeError

np.duckarray(SparseArray())  # returns a SparseArray object
np.array(SparseArray())  # raises TypeError

여기에서는 np.duckarray 및 __duckarray__ 를 자리 표시 자로 사용했지만 이러한 이름에 대해 더 잘 할 수 있습니다. NEP 22의 용어 를 참조하십시오.

"Duck array"는 현재 자리 표시 자로 잘 작동하지만 꽤 전문 용어이며 새로운 사용자를 혼동 할 수 있으므로 실제 API 기능에 대해 다른 것을 선택하는 것이 좋습니다. 안타깝게도 "배열과 유사한"은 이미 "배열로 강제 변환 될 수있는 모든 것"(예 : 목록 객체 포함)의 개념으로 채택되었으며 "anyarray"는 이미 "ndarray의 구현을 공유하는 것"의 개념으로 채택되었지만 has different semantics”는 duck 배열의 반대입니다 (예 : np.matrix는“anyarray”이지만“duck array”는 아님). 이것은 고전적인 자전거 창고이므로 지금은 "오리 배열"을 사용하고 있습니다. 가능한 옵션으로는 arrayish, pseudoarray, nominalarray, ersatzarray, arraymimic,…

다른 이름 아이디어 : np.array_compatible() , np.array_api() ....

np.array_compatible 는 작동 할 수 있지만 duckarray 보다 좋은지 잘 모르겠습니다. np.array_api 싫어요, 잘못된 생각을 해요 imho.

오랜만에 더 나은 이름이 나오지 않았기 때문에 아마도 "오리 배열"이라는 이름을 축복해야 할 것 같습니다 ...

나는 호환되는 단어를 좋아한다. 아마도 우리는 as_compatible_array 뿐만 아니라 그 라인을 따라 변형 된 것을 생각할 수있을 것이다. (다소 호환되는 모든 객체가 배열이라는 것을 의미한다). as 은 (부분적으로는 모든 as 함수에 공백이 없기 때문에) 성 가실 수 있습니다. "duck"은 도서관에서는 멋져 보이지만 무작위로 보는 사람들에게는 조금 이상하다고 생각합니다. 따라서 다운 스트림 사용자가 많이 사용하기를 원하는 경우에만 "duck"을 싫어한다고 생각합니다 (예 : 나 자신 / 작은 실험실을위한 작은 도구를 작성하기 시작하는 경우에도).

아마도 quack_array :)

주제를 조금 확장하기 위해 np.duckarray 다루지 않는 다른 사례가 있습니다. np.empty_like 과 같은 함수와 유사한 기존 유형을 기반으로 한 유형으로 새 배열을 생성하는 것입니다.

>>> import numpy as np, cupy as cp
>>> a  = cp.array([1, 2])
>>> b = np.ones_like(a)
>>> type(b)
<class 'cupy.core.core.ndarray'>

반면에 NumPy의 API를 통해 CuPy 배열을 생성하려는 array_like 가 있다면 불가능합니다. 나는 다음과 같은 것을 갖는 것이 도움이 될 것이라고 생각합니다.

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.asarray(b, like=a)

이것에 대한 아이디어 / 제안이 있습니까?

어쩌면 np.copy_like? 우리는 어떤 속성을 신중하게 정의하고 싶을 것입니다.
(예 : dtype 포함 여부) 다른 배열에서 복사됩니다.

2019 년 7 월 1 일 월요일 오전 5:40 Peter Andreas Entschev <
[email protected]> 작성 :

주제에 대해 조금 더 설명하기 위해 다루지 않은 사례가 하나 더 있습니다.
np.duckarray를 사용하여 유형 기반으로 새 배열을 생성합니다.
np.empty_like와 같은 함수가 수행하는 것과 유사한 기존 유형에서.
현재 다음과 같이 할 수 있습니다.

numpy를 np로, 큐피를 cp로 가져 오기 >>> a = cp.array ([1, 2]) >>> b = np.ones_like (a) >>> type (b)

반면에 우리가 만들고 싶은 array_like가 있다면
NumPy의 API를 통한 CuPy 어레이는 불가능합니다. 나는 그것이 될 것이라고 생각한다
다음과 같은 것을 갖는 것이 도움이됩니다.

numpy를 np로, cupy를 cp로 가져 오기
a = cp.array ([1, 2])
b = [1, 2]
c = np.asarray (b, like = a)

이것에 대한 아이디어 / 제안이 있습니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVRCWDHRAXHHRDHXXM3P5H3LRA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFWSVREXG43VMVORBW63LN5WWWY702 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAJJFVRSYHUYHMPWQTW2NLLP5H3LRANCNFSM4H3HQWAA
.

np.copy_like 도 좋을 것 같습니다. 동의합니다. dtype 같은 것을 제어 할 수있는 방법이있을 것 같습니다.

초보자의 질문에 대해 죄송합니다. np.copy_like 와 같은 것이 NEP-22의 수정안이어야하나요? 메일 링리스트에서 논의해야하나요? 아니면 가장 적절한 접근 방식은 무엇인가요?

우리는 이것에 대한 엄격한 규칙을 가지고 있지 않지만 np.copy_like 및 np.duckarray (또는 우리가 부르는 모든 것)를 오리 배열을 강제 / 생성하는 새로운 NEP에 함께 넣는쪽으로 기울일 것입니다. 그것은 NEP 22와 같은 "정보"라기보다는 NEP 18과 같은 규범 적입니다. 길어야 할 필요는 없습니다. 대부분의 동기는 NEP 18/22를 참조함으로써 이미 분명합니다.

np.copy_like() 에 대한 참고 사항 : __array_function__ (또는 이와 유사한 것)로 디스패치를 ​​수행해야하므로 np.copy_like(sparse_array, like=dask_array) 와 같은 작업은 두 배열 유형 중 하나에서 정의 할 수 있습니다.

좋습니다. 정보를 제공해 주셔서 감사합니다. 귀하의 파견 제안에 동의합니다. 저는 np.duckarray 및 np.copy_like 구현을위한 NEP 작업을 수행하고 이번 주에 PR 초안을 제출할 것입니다.

대단해, 고마워 피터!

2019 년 7 월 1 일 월요일 오전 9:29 Peter Andreas Entschev <
[email protected]> 작성 :

좋습니다. 정보를 제공해 주셔서 감사합니다. 귀하의 파견 제안에 동의합니다. 나는
NEP에서 np.duckarray 및
np.copy_like 및 이번 주 PR 초안을 제출하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVW2YUBNUCJZK6JWDBTP5IWHNA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFWSVREXG43ZVMV3QW63LNMVXHJW63LNMVXHJW63LNMVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAJJFVR2KTPAZ4JPWDYYMFLP5IWHNANCNFSM4H3HQWAA
.

이 작업에 대한 아이디어와 지원에 감사드립니다!

array_like 및 copy_like 함수는 기본 네임 스페이스에있는 것이 약간 이상 할 것입니다. cupy / dask / sparse / etc), 맞습니까? 재정의 된 경우에만 유용합니다. 아니면 여기에 임의의 비 numpy 배열 객체를 만드는 방법이 없습니까?

사실, 이것은 오리 타이핑을 지원하려는 경우에만 실제로 유용합니다. 그러나 확실히 np.duckarray 및 np.copy_like 인수가 NumPy 배열 인 경우에도 작동합니다. np.array / np.copy 합니다.

모든 배열 구현에는 copy 메서드가 있습니까? copy_like 대신 사용하면 작동하므로 새 함수를 추가하는 이유는 무엇입니까?

array_like 필요성을 알 수 있지만 어디에 넣을지 논의하고 싶을 수도 있습니다.

np.duckarray 이 (가) 이해가됩니다.

나는 np.copy_like와 np.duckarray (또는 우리가 부르는 무엇이든)를 NEP 22와 같은 "Informational"이 아닌 NEP 18과 같은 규범적인 오리 배열을 강제 / 생성하는 새로운 NEP에 함께 넣는쪽으로 기울일 것입니다.

+1

array_like에 대한 필요성을 알 수 있지만 어디에 넣을지 논의하고 싶을 수도 있습니다.

실제로 np.copy_like 와 같이 다루고 싶은 경우입니다. 테스트하지는 않았지만 배열이 NumPy가 아닌 경우 np.copy 이미 올바르게 전달됩니다.

명확히하기 위해 np.array_like 함수도 언급하고 있습니까? array_like -arrays에 대한 기존의 모든 참조가 혼동 될 수 있다고 생각했기 때문에 의도적으로 그러한 이름을 피했습니다. 그러나, 나는 이제 깨닫는다 np.copy_like 필요한 사본을 의미 할 수 있으며, 나는 그것이 유사한 행동해야하는 것이 좋을 것이라고 생각 np.asarray 가 이미 NumPy와 아니라면 복사 만 발생, 정렬. 여기에서 설명하는 경우 가장 좋은 방법은 np.copy_like(a, like=b) 와 같은 호출에서 a 가 b 와 동일한 유형이 아닌 경우에만 복사하는 것입니다.

테스트하지는 않았지만 배열이 NumPy가 아닌 경우 np.copy 이미 올바르게 전달됩니다.

__array_function__ 을 지원하도록 장식되어 있어야합니다.

명확히하기 위해 np.array_like 함수도 언급하고 있습니까? array_like-arrays에 대한 기존의 모든 참조에 혼동을 줄 수 있다고 생각했기 때문에 의도적으로 그러한 이름을 피했습니다.

예. 그리고 네, 혼란 스러울 수 있다는 데 동의합니다.

그러나 이제 np.copy_like 가 필요한 사본을 의미 할 수 있다는 것을 알고 있습니다.

예, 그 이름은 데이터 사본을 의미합니다.

필요한 사본을 암시 할 수 있으며 np.asarray 와 유사한 동작을하는 것이 좋을 것이라고 생각합니다.

나는 그것이 np.duckarray 라고 생각했습니다.

위의 Peter의 예가 이것을 명확히하는 데 도움이 될 것이라고 생각합니다. 단순성을 위해 아래에서 복사하고 np.copy_like 에 자막을 추가했습니다.

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.copy_like(b, like=a)

나는 그것이 np.duckarray라고 생각했습니다.

실제로 np.duckarray 는 기본적으로 아무것도하지 않고 배열 자체를 반환하고 (재정의 된 경우) 그렇지 않으면 np.asarray 반환합니다 (NumPy 배열로 이어짐). 예를 들어 Python 목록에서 CuPy 배열을 가져올 수 없습니다. array_like 대해 CuPy (또는 다른 like= 배열)로 전달할 수있는 함수가 여전히 필요합니다.

업데이트 된 예제에 대해 @jakirkham 에게 감사드립니다.

c = np.copy_like(b, like=a)

그러면 a.__array_function__ 를 통해 CuPy로 전달되고 해당 속성이 존재하지 않으면 실패합니까 (예 : a=<scipy.sparse matrix> 작동하지 않음)? 이러한 종류의 작업을 위해 새로운 네임 스페이스 또는 새로운 상호 운용성 유틸리티 패키지가 필요한 것 같습니다. 아니면 간단하게 할 수있는보다 완전한 기능의 미래 디스패치 메커니즘에 맡기십시오.

with cupy_backend:
   np.array(b)

NumPy 자체가 __array_function__ 의 제한을 우회하는 작업을 지원하지 않는 메인 네임 스페이스에 새로운 기능을 도입하는 것은 약간 비정상적인 것 같습니다 ....

그러면 a.__array_function__ 를 통해 CuPy로 전달되고 해당 속성이 존재하지 않으면 실패합니까 (예 : a=<scipy.sparse matrix> 작동하지 않음)?

반드시 실패해야한다고 말하지는 않겠습니다. 예를 들어 기본적으로 NumPy를 사용하여 경고를 발생시킬 수 있습니다 (또는 전혀 발생시키지 않음).

이러한 종류의 작업을 위해 새로운 네임 스페이스 또는 새로운 상호 운용성 유틸리티 패키지가 필요한 것 같습니다. 아니면 더 완전한 기능을 갖춘 미래 디스패치 메커니즘에 맡기십시오.

확실히 모든 기능을 갖춘 디스패치 메커니즘을 갖는 것이 좋겠지 만, 복잡성과 하위 호환성 문제로 인해 이전에 수행되지 않았던 것 같습니다. 나는 토론이 일어 났을 때 주변에 없었기 때문에 추측 만했습니다.

NumPy 자체가 __array_function__의 한계를 해결하는 것을 지원하지 않는 새로운 기능을 메인 네임 스페이스에 도입하는 것은 약간 비정상적인 것 같습니다 ....

나는 당신의 요점을 확실히 알고 있지만, 우리가 메인 네임 스페이스에서 너무 많은 것을 옮기면 사용자들이 겁을 먹을 수 있다고 생각합니다. 어쩌면 내가 틀렸을 수도 있고 이것은 단지 인상 일뿐입니다. 어느 쪽이든, 나는 NumPy와 함께 작동하지 않는 기능을 구현할 것을 전혀 제안하지 않았지만 NumPy를 단독으로 사용할 때 절대적으로 필요하지 않을 수도 있습니다.

NumPy 자체가 __array_function__의 한계를 해결하는 것을 지원하지 않는 새로운 기능을 메인 네임 스페이스에 도입하는 것은 약간 비정상적인 것 같습니다 ....

실제로 이런 의미에서 np.duckarray 메인 네임 스페이스에 속하지 않습니다.

실제로 이런 의미에서 np.duckarray 메인 네임 스페이스에 속하지 않습니다.

나는 하나가 더 방어 적이라고 생각합니다 ( asarray 와 유사하며 기본적으로 "이것은 ndarray와 유사한 오리 유형의 정의를 충족합니까"). 우리가 array_function_dispatch 도 공개하고 싶고 np.lib.mixins.NDArrayOperatorsMixin 있고 더 많은 믹스 인을 작성할 계획이라면 상호 운용성과 관련된 모든 것을위한 현명한 새 하위 모듈이 합리적 일 수 있습니다.

확실히 모든 기능을 갖춘 디스패치 메커니즘을 갖는 것이 좋겠지 만, 복잡성과 하위 호환성 문제로 인해 이전에 수행되지 않았던 것 같습니다. 나는 토론이 일어 났을 때 주변에 없었기 때문에 추측 만했습니다.

여러 가지 이유가 있다고 생각합니다. __array_function__ 는 우리가 이미 가지고있는 것과 유사하므로 추론하기가 더 쉽습니다. 오버 헤드가 적습니다. 6 개월 이내에 설계하고 구현할 수 있었고

상호 운용성과 관련된 모든 것을위한 합리적인 새 하위 모듈이 의미가있을 수 있습니다.

나에게 진짜 이의가 없습니다. 아무데도없는 것보다는 어딘가에 기능을 갖는 것이 낫다고 생각합니다. :)

여러 가지 이유가 있다고 생각합니다. __array_function__은 우리가 이미 가지고있는 것과 비슷하므로 추론하기가 더 쉽습니다. 오버 헤드가 적습니다. 6 개월 이내에 설계하고 구현할 수 있었고

그러나 __array_function__ 더 광범위하게 활용하려면 np.duckarray 및 np.copy_like (또는 다른 이름으로 부르기로 결정)과 같은 것을 구현하는 다른 대안이 있습니까? 나는 모든 대안에 개방적이지만, 당장은 완전한 기능을 갖춘 디스패치 방식보다는 시간이 오래 걸리고 __array_function__ 의 범위를 제한 할 가능성이있는 것보다 당장은 아무것도 보지 못합니다

그러나 __array_function__ 더 광범위하게 활용하려면 np.duckarray 및 np.copy_like (또는 다른 이름으로 부르기로 결정)과 같은 것을 구현하는 다른 대안이 있습니까?

일부 사용 사례에서 80 % 이상의 사용 사례로 이동하려면 이와 같은 유틸리티 기능 세트가 실제로 필요하다고 생각합니다. 나는 그 주위에 방법이 없다고 생각합니다. 메인 네임 스페이스를 어수선하게 만드는 것을 좋아하지 않으므로 더 나은 장소를 찾을 것을 제안합니다.

나는 모든 대안에 개방적이지만, 당장은 완전한 기능을 갖춘 디스패치 방식보다는 시간이 오래 걸리고 __array_function__ 의 범위를 제한 할 가능성이있는 것보다 당장은 아무것도 보지 못합니다

내 말은, 우리는 여기에 몇 가지 명백한 구멍을 막는 것입니까? "더 복잡한 경우"를 모두 다루지는 않을 것입니다. np.errstate 또는 np.dtype 를 재정의하려는 경우 프로토콜 기반 접근 방식에서는 이러한 현상이 발생하지 않습니다.

대안으로, uarray 는 아직 존재하지 않으며, 오버 헤드가 NumPy에서 기본적으로 사용될 수있을만큼 충분히 낮아질 것이라고 확신하지 못하지만, 점점 가까워지고 있으며 scipy.fft 를 생성하려고 시도합니다 https://github.com/Quansight-Labs/uarray/tree/master/unumpy

uarray를 사용한 파견 접근 방식은 확실히 흥미 롭습니다. 메타 어레이 (Dask, xarray 등)를 처리하는 방법에 대해 여전히 우려하고 있습니다. 자세한 내용은 이 설명 을 참조하십시오. 이 문제가 해결되었는지 확실하지 않습니다 (하지만 뭔가 놓친 경우 수정 해주세요). 저는 SciPy의 다른 사람들과 함께이 문제를 해결하는 방법을 시도하고 해시하는 데 관심이 있습니다.

자세한 내용은이 설명을 참조하십시오. 이 문제가 해결되었는지 확실하지 않습니다 (하지만 뭔가 놓친 경우 수정 해주세요).

지난주의 변경 사항이 해결되었다고 생각하지만 확실하지 않습니다. 다른 스레드에 맡기겠습니다.

저는 SciPy의 다른 사람들과 함께이 문제를 해결하는 방법을 시도하고 해시하는 데 관심이 있습니다.

내가 거기있을 게, 직접 만나서 반가워요.

np.coerce_like() 또는 np.cast_like() 가 copy_like 보다 더 나은 이름 일 수 있으므로 복사본이 반드시 필요한 것은 아닙니다. 원하는 기능은 실제로 .cast() 메서드와 매우 유사합니다. 단, 배열 유형과 dtype을 변환하려는 경우를 제외하고는 프로토콜이 아닌 함수 여야하므로 두 인수로 구현할 수 있습니다.

uarray를 사용한 파견 접근 방식은 확실히 흥미 롭습니다. 메타 어레이 (Dask, xarray 등)를 처리하는 방법에 대해 여전히 우려하고 있습니다.

uarray 은 (는) 여러 백엔드를 지원하므로 이와 같은 것이 작동합니다.

with ua.set_backend(inner_array_backend), ua.set_backend(outer_array_backend):
  s = unumpy.sum(meta_array)

이는 구현 내에서 메타 배열이 ua.skip_backend 호출하도록하거나 메타 배열의 백엔드가 유형 불일치시 NotImplemented 를 반환하는 경우 수행 할 수 있습니다.

참조 : @hameerabbasi

이에 대해 확장하겠습니다. 일반적으로 dask.array 경우 da 이있는 모든 항목은 skip_backend없이 작성됩니다. NumPy가있는 모든 것은 skip_backend가 필요합니다.

또는 da 언제든지 디스패치를 ​​건너 뛰고 직접 구현을 호출하고 skip_backend(dask.array) 모든 곳에서 사용할 수 있습니다.

ones , cast 와 같이 배열이 연결되지 않은 함수를 디스패치하려면 백엔드를 설정하면됩니다. np.errstate 및 np.dtype 합니다. np.ufunc 에서 unumpy np.ufunc 를 다루는 예가 있습니다.

원래 문제에 관해서는 uarray 에서 __ua_convert__ 프로토콜을 제공합니다. 대안은 백엔드가 asarray 직접 재정의하는 것입니다.

uarray , @rgommers , @ peterbell10 , @hameerabbasi에 대해 알려 주셔서 감사합니다.

하지만 내가 보는 것처럼 계산을 시작하기 전에 적절한 백엔드를 설정해야합니다. 맞습니까? __array_function__ 의 장점 중 하나는 Dask가 CuPy의 존재를 알 필요가없는 것과 같이 라이브러리가 다른 라이브러리와 완전히 무관 할 수 있다는 것입니다.

@pentschev 이것은 백엔드를 "등록"하는 기능을 추가 한 최근까지의 경우 였지만 NumPy (또는 참조 구현) 만이를 수행하는 것이 좋습니다. 그러면 Dask를 사용하는 사용자는 하나의 set_backend 만 필요합니다.

그것은, 내가이 언급 @rgommers 무엇을 추측있어 https://github.com/numpy/numpy/issues/13831#issuecomment , -507432311의 백엔드를 가리키는 https://github.com/Quansight-Labs/uarray / tree / master / unumpy.

너무 많은 질문에 대해 죄송합니다.하지만 가상 애플리케이션이 NumPy 및 Sparse와 같은 다양한 백엔드에 의존하는 경우 사용자 입력에 따라 모든 것이 NumPy 전용, Sparse 전용 또는 둘 다 혼합 될 수 있습니다. @ peterbell10 은 여러 백엔드가 지원 https://github.com/numpy/numpy/issues/13831#issuecomment -507458331 그러나 백엔드 선택을 자동으로 할 수 있습니까? 아니면 세 가지 경우를 개별적으로 처리해야합니까?

따라서이 경우 이상적으로는 NumPy를 등록하고 Sparse 용 컨텍스트 관리자를 사용하고 적절한 경우 sparse에서 NotImplemented 를 반환하면 NumPy로 대체됩니다.

SciPy에서 @rgommers , @danielballan , 그리고 나 자신이이 문제에 대해 이야기했습니다. duckarray (해당 이름 사용)을 계속 추가하는 것이 중요하다고 결론지었습니다. 즉, 이것은 1.18로 예정된 것처럼 들렸습니다. 내가 잘못 이해하면 나를 바로 잡아주세요. 이것을 감안할 때 PR을 시작해도 괜찮을까요?

duckarray (해당 이름 사용)을 계속 추가하는 것이 중요하다고 결론지었습니다. 즉, 이것은 1.18로 예정된 것처럼 들렸습니다. 내가 잘못 이해하면 나를 바로 잡아주세요. 이것을 감안할 때 PR을 시작해도 괜찮을까요?

이 모든 것이 나에게는 훌륭하게 들리지만 정확한 제안을 설명하는 짧은 NEP로 시작하는 것이 좋습니다. https://github.com/numpy/numpy/issues/13831#issuecomment -507334210 참조

당연합니다. 🙂

이전에 제기 된 카피 요점은 기존 메커니즘으로 해결되지 않는지 궁금합니다. 특히이 라인은 어떻습니까?

a2 = np.empty_like(a1)
a2[...] = a1[...]

분명히 이것을 한 줄로 줄이는 것이 좋을 것입니다. 이것이 이미 해당 사용 사례에서 작동하는지 또는 누락 된 것이 있는지 궁금합니다.

우리는 (해당 이름을 사용하여) duckarray를 추가하는 것이 가치가 있다고 결론지었습니다.

이 모든 것이 나에게는 훌륭하게 들리지만 정확한 제안을 설명하는 짧은 NEP로 시작하는 것이 좋습니다. # 13831 (코멘트) 참조

나는 이미 그것을 쓰기 시작했지만 아직 완료하지 못했습니다 (나의 나쁜 계획 https://github.com/numpy/numpy/issues/13831#issuecomment-507336302에 대해 죄송합니다).

이전에 제기 된 카피 요점은 기존 메커니즘으로 해결되지 않는지 궁금합니다. 특히이 라인은 어떻습니까?

a2 = np.empty_like(a1)
a2[...] = a1[...]

분명히 이것을 한 줄로 줄이는 것이 좋을 것입니다. 이것이 이미 해당 사용 사례에서 작동하는지 또는 누락 된 것이 있는지 궁금합니다.

그렇게 할 수는 있지만 특수한 복사 로직이 필요할 수 있습니다 (예 : CuPy https://github.com/cupy/cupy/pull/2079).

즉, 이러한 종류의 추가 코드가 필요하지 않도록하려면 복사 기능이 가장 좋습니다.

반면에 이것은 asarray 대한 일종의 대체물입니다. 그래서 copy_like 새로운 기능 대신 NEP-18에서 제안한 아이디어 를 다시 검토하고 싶은지 궁금합니다.

여기에는 자체 프로토콜이 필요합니다.
...
array와 asarray는 실제 numpy.ndarray 객체로 강제 변환하기위한 것이기 때문입니다.

다시 방문하고 싶은 경우 새 스레드를 시작하는 것이 좋습니다. 아이디어, 제안, 이의가 있습니까?

위의 의견을 명확히하기 위해 새로운 프로토콜이 좋은 아이디어인지 (아마도 예상하지 못했던 많은 성가신 세부 사항이 포함되어 있는지) 모르겠습니다. 그게 우리가 다시 검토하고 논의해야하는 아이디어인지 궁금합니다. .

SciPy'19의 개발 회의 및 스프린트의 합의는 다음과 같습니다. 다음 단계를 수행하기 전에 1.17.0을 문 밖으로 꺼내 실제 경험을 얻으십시오.

그것이 우리가 재검토하고 논의해야하는 아이디어인지 정말로 궁금합니다.

아마도 예,하지만 몇 달 후에.

아마도 예,하지만 몇 달 후에.

좋아, 답장을 보내 주셔서 감사합니다!

이전에 제기 된 카피 요점은 기존 메커니즘으로 해결되지 않는지 궁금합니다. 특히이 라인은 어떻습니까?

a2 = np.empty_like(a1)
a2[...] = a1[...]

분명히 이것을 한 줄로 줄이는 것이 좋을 것입니다. 이것이 이미 해당 사용 사례에서 작동하는지 또는 누락 된 것이 있는지 궁금합니다.

이것과 관련된 내 주요 문제는 변경 불가능한 오리 배열에서는 작동하지 않는다는 것입니다. 또한 NumPy의 경우 배열을 할당 한 다음 채우는 추가 비용이 거의 0 일 수 있지만 모든 오리 배열에 해당하는 것은 아닙니다.

이전에 제기 된 카피 요점은 기존 메커니즘으로 해결되지 않는지 궁금합니다. 특히이 라인은 어떻습니까?

a2 = np.empty_like(a1)
a2[...] = a1[...]

분명히 이것을 한 줄로 줄이는 것이 좋을 것입니다. 이것이 이미 해당 사용 사례에서 작동하는지 또는 누락 된 것이 있는지 궁금합니다.

그렇게 할 수는 있지만 특별한 복사 논리가 필요할 수 있습니다 (예 : CuPy cupy / cupy # 2079 ).

즉, 이러한 종류의 추가 코드가 필요하지 않도록하려면 복사 기능이 가장 좋습니다.

반면에 이것은 asarray 대한 일종의 대체물입니다. 그래서 copy_like 새로운 기능 대신 NEP-18에서 제안한 아이디어 를 다시 검토하고 싶은지 궁금합니다.

여기에는 자체 프로토콜이 필요합니다.
...
array와 asarray는 실제 numpy.ndarray 객체로 강제 변환하기위한 것이기 때문입니다.

다시 방문하고 싶은 경우 새 스레드를 시작하는 것이 좋습니다. 아이디어, 제안, 이의가 있습니까?

새 프로토콜로 np.array 또는 np.asarray 의 동작을 변경하는 것은 좋은 생각이 아니라고 생각합니다. 그들의 확립 된 의미는 NumPy 배열로 캐스트하는 것이므로 기본적으로 np.duckarray 가 필요합니다.

즉, duckarray like 인수를 추가하는 것을 고려할 수 있습니다. 아마도 사용하는 - 즉, 위의 단순화 제안에서 프로토콜을 변경 필요 __array_function__ 대신 같은 전용 프로토콜 __duckarray__ ? 나는 이것을 정말로 생각하지 않았다.

이전에 제기 된 카피 요점은 기존 메커니즘으로 해결되지 않는지 궁금합니다. 특히이 라인은 어떻습니까?

a2 = np.empty_like(a1)
a2[...] = a1[...]

분명히 이것을 한 줄로 줄이는 것이 좋을 것입니다. 이것이 이미 해당 사용 사례에서 작동하는지 또는 누락 된 것이 있는지 궁금합니다.

이것과 관련된 내 주요 문제는 변경 불가능한 오리 배열에서는 작동하지 않는다는 것입니다. 또한 NumPy의 경우 배열을 할당 한 다음 채우는 추가 비용이 거의 0 일 수 있지만 모든 오리 배열에 해당하는 것은 아닙니다.

공정 해. 사실 우리는 이미 일을 단순화 할 수 있습니다. 예를 들어 이것은 오늘날 CuPy 및 Sparse에서 작동합니다.

a2 = np.copy(a1)

공정 해. 사실 우리는 이미 일을 단순화 할 수 있습니다. 예를 들어 이것은 오늘날 CuPy 및 Sparse에서 작동합니다.

a2 = np.copy(a1)

예,하지만 "이 덕 어레이를 다른 덕 어레이 유형에 복사"하는 것도 원합니다.

새 프로토콜로 np.array 또는 np.asarray 의 동작을 변경하는 것은 좋은 생각이 아닙니다. 그들의 확립 된 의미는 NumPy 배열로 캐스트하는 것이므로 기본적으로 np.duckarray 가 필요합니다.

나도 이것에 대해 확신이없고,이 질문을 제기하는 것조차 꺼려했다. 이것이 내가 오늘까지하지 않은 이유이다.

즉, duckarray에 like 인수를 추가하는 것을 고려할 수 있습니다. 위의 단순화 된 제안에서 프로토콜을 변경해야합니다. __duckarray__와 같은 전용 프로토콜 대신 __array_function__을 사용할 수 있습니까? 나는 이것을 정말로 생각하지 않았다.

그것과 합병증이 있는지는 모르겠지만 우리는 아마도 조심해야 할 것입니다.하지만 저는이 아이디어를 좋아하는 경향이 있습니다. 다양한 수준에서 중복 된 것처럼 보이지만 like 매개 변수를 추가하는 대신 duckarray 및 duckarray_like ?

예,하지만 "이 덕 어레이를 다른 덕 어레이 유형에 복사"하는 것도 원합니다.

np.copyto 어떨까요?

np.copyto 어떨까요?

내가 틀렸다면 자유롭게 정정하십시오.하지만 다음과 같은 의미를 가지고 있다고 가정합니다.

np.copyto(cupy_array, numpy_array)

NumPy가 현재 동작을 기꺼이 변경한다고 가정하면 작동 할 수 있습니다. 예를 들어 asarray 항상 대상이 NumPy 배열임을 의미합니다. copyto 는 동일한 가정을 수행합니까?

np.copyto 이미 __array_function__ 사용한 디스패치를 ​​지원하지만 대략 다음과 같습니다.

def copyto(dst, src):
    dst[...] = src

우리는 다음과 같은 것을 원합니다.

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

np.copyto 이미 __array_function__ 사용한 디스패치를 ​​지원하지만 대략 다음과 같습니다.

def copyto(dst, src):
    dst[...] = src

우리는 다음과 같은 것을 원합니다.

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

맞습니다. 이것이 우리가 원하는 것입니다. copyto 가 발송되고 소스와 대상의 유형이 동일한 경우 작동합니다. 대상 배열의 라이브러리로 발송할 수있는 것이 필요합니다.

copyto 는 우리가 어떻게 생각하는지에 따라 여전히 의미가있을 수 있습니다. 예를 들어 다음 사용 사례를 살펴보십시오.

np.copyto(cp.ndarray, np.random.random((3,)))

이것은 우리가 논의한 바와 같이 데이터 할당 및 복사와 같은 것으로 변환 될 수 있습니다. dst (이 경우 cp.ndarray 주위를 디스패치하면 불변 배열이있는 라이브러리도이를 적절한 방식으로 구현할 수 있습니다. 또한 NumPy가 단순히 제공하지만 사용하지 않는 새로운 API를 추가하지 않아도됩니다.

최근 저에게 떠오른 또 다른 생각을 표면화하기 위해 이러한 API가 다른 라이브러리 간의 다운 스트림을 의미하는 것이 무엇인지 생각해 볼 가치가 있습니다 (예 : Dask와 Xarray의 상호 작용 방식).