첫 번째 예시에서 b의 타입만 보고 문서를 보면 읽기 어렵지만, 반환되는 shape에 대한 설명이 있으므로 실제로 b 벡터가 행렬 형태인지(특히 K=1인 경우) 확인해야 함
배열의 차원이 2개가 넘으면 Numpy 배열에 차원 이름을 추가해주는 Xarray를 쓰는 것을 추천함, 차원 맞추기나 transpose 작업 없이 브로드캐스팅/정렬이 자동이라 이런 문제의 대부분이 해결됨, Xarray는 선형대수 측면에서는 NumPy보다 약하지만 쉽게 NumPy로 돌아갈 수 있고 도우미 함수만 만들면 됨, Xarray를 쓰면 3차원 이상의 데이터 다룰 때 생산성이 크게 높아짐임
Xarray는 Pandas와 NumPy의 장점을 합친 느낌임, da.sel(x=some_x).isel(t=-1).mean(["y", "z"]) 같은 인덱싱이 쉽고, 차원 이름이 존중되어 브로드캐스팅도 명확함, 여러 CRSs의 지리공간 데이터 처리에 강점이 있음, Arviz와의 활용도 탁월해서 베이지안 분석에서 추가 차원 처리도 쉬움, 여러 배열을 하나의 dataset에 묶어서 공통된 좌표도 공유 가능해 ds.isel(t=-1)처럼 시간 축을 가진 모든 배열에 쉽게 동작시킬 수 있음
Xarray 덕분에 초보적인 NumPy 사용이 많이 줄고 훨씬 생산성이 오름
Tensorflow, Keras, Pytorch 같은 프레임워크엔 비슷한 게 있는지 궁금함, 예전에 언급한 내용을 어렵게 디버깅했던 기억이 있음
소개 고맙고 꼭 써볼 계획임, array[:, :, None] 같은 문법이 불편했던 건 자신만 그런 줄 알았는데 같은 의견이라 반가움
biosignal 분야에선 NeuroPype가 NumPy 위에서 n차원 텐서용 이름 붙은 축 지원과 각 축별로 per-element 데이터(채널명, 위치 등) 저장 가능함
NumPy가 예전 Numeric과 Numarray 라이브러리에서 파생되던 시점이 떠오름, Numarray 파가 20년 동안 계속 주장을 이어오다 자금을 받고 Xarray로 이름을 바꿔 이제 NumPy를 이겼다고 상상해봄(물론 대부분 허구임)
Julia를 쓰기 시작한 이유 중 하나는 NumPy 문법이 너무 어려웠기 때문임, MATLAB에서 NumPy로 넘어가니 프로그래밍이 더 서툴러져서 수학보다 성능 트릭을 익히는 데 시간을 썼음, Julia에선 벡터화도 루프도 잘 동작해 코드 가독성에만 신경 쓸 수 있음, 이런 경험과 감정을 글에서 그대로 느꼈음, np.linalg.solve 같은 걸 최고로 빠르다고 생각해서 무조건 맞춰 쓰라는 식의 ‘블랙박스’ 접근은 옳지 않다고 봄, 문제 특화 커널을 직접 짜는 게 더 나은 여러 이유도 존재함
Julia가 과학 계산용으로 설계된 언어이고 NumPy는 과학 계산용이 아닌 언어 위에 억지로 얹힌 라이브러리라는 점이 원인임, 언젠가 Julia가 승리해서 네트워크 효과 때문에 파이썬을 쓰는 사람들이 해방되길 바람
MATLAB도 벡터화 없이 루프 돌리면 Python만큼 느림, Python의 느림이 가장 큰 문제이고 Julia는 분명 장점이 있지만 실제로는 급격하게 한정적인 용도에 밖에 못 씀, Python엔 JIT hack 같은 게 생겼지만 여전히 불완전함, Python 대안이 절실함
MATLAB이 정말 다를까? 루프가 느린 것은 변함없고, 가장 빠른 건 '' 연산자처럼 완전히 최적화된 블랙박스임
Fortran 최신 버전도 Julia처럼 벡터화와 루프 모두 빠르게 동작하므로 가독성에만 집중 가능함
Matlab, Julia 대비 numpy의 불만을 정리하면, 함수마다 축 관련 인자와 네이밍, 벡터화 제공 방식이 제각각이고, 어떤 축에 함수 적용하려면 코드를 완전히 다시 써야 한다는 점임, 프로그래밍의 기본이 추상화인데 NumPy는 이를 어렵게 함, Matlab에선 벡터화 코드는 거의 그대로 돌아가거나 수정이 명확하지만 NumPy는 항상 문서를 뒤져보고 transpose/reshape 등 타입 맞추기가 일관되지 않아 애매함
Matlab의 3차원 이상 배열 지원이 너무 약해 오히려 글에서 언급된 문제는 잘 생기지 않음
두 번째 문제는 jax의 vmap을 시도해볼 만함
2x2 배열에 특정 함수 작성 후 3x2x2 배열의 일부에 적용하고 싶다는 건 슬라이스와 squeeze 등으로 가능함, 이 문제 자체가 이해가 안 갈 정도로 애매함
reshape로 처리 가능함
numpy에서 가장 혼란스러운 점은 어떤 연산이 벡터화되어 동작하나 명확하지 않고, Julia처럼 dot 문법으로 명시할 수 없다는 것임, 반환 타입 관련해서도 다양한 함정이 많음, 예를 들어 poly1d 객체 P를 오른쪽에서 z0로 곱하면 poly1d가 나오지만 왼쪽에서 z0*P 형태로 곱하면 배열만 반환되어 타입 변환이 조용히 일어남, quadratic의 leading coefficient도 P.coef[0]과 P[2] 두 방식이 가능해서 혼란하기 쉬움, 공식적으로 poly1d는 ‘오래된’ API이고 새 코드는 Polynomial 클래스를 권장하지만 실제로는 deprecated 경고도 없음, 이런 타입 변환과 데이터타입의 불일치처럼 라이브러리 곳곳에 지뢰가 있어서 디버깅 악몽임
저자가 지적한 내용에 공감함, Matlab에서 Numpy로 갈 때 불편함이 많았고, 데이터 슬라이싱도 Numpy가 Matlab/Julia보다 더 불편하다고 느낌, 하지만 Matlab의 toolbox 라이선스 비용을 감안하면 Numpy의 단점이 커버됨, 글에서 제시한 문제는 2차원 초과 텐서에서 주로 발생하며 Numpy는 원래 행렬(2D) 기반이니 그 한계가 당연함, Torch 같은 전용 라이브러리가 낫지만 그것도 쉽진 않음, 결국 "NumPy는 다른 어떤 array 언어들보다 약간 더 별로지만 그렇다고 쓸 수 있는 게 별로 없음"이 정답인 느낌임
Numpy는 최초부터 N차원 배열을 목표로 numarray의 연장선에 있었으므로 2D에만 머문 것은 아님
Python 데이터 사이언스 생태계의 가장 큰 문제는 모든 것이 비표준임, 10여 개의 라이브러리가 4개 언어만큼 각기 다르게 동작하고 그나마 to_numpy() 정도만 통일됨, 결국 문제를 푸는 시간보다 데이터 포맷 변환에 시간이 더 소모됨, Julia도 장점만 있는 건 아니지만 단위 및 불확실성 등 다양한 라이브러리 간 연동이 잘 되고 Python은 항상 보일러플레이트 코드가 많이 필요함
일부 문제는 numpysane와 gnuplotlib을 쓰면 해결됨, 이 조합이 생긴 후 numpy를 모든 작업에 적극 활용함, 없었다면 도저히 못 쓸 수준임
numpysane는 결국 파이썬 루프임, 실제 벡터화와는 다름
소개 고맙고, 이런 문제로 종종 투덜거렸기에 간단한 상위 라이브러리가 있단 생각을 못 했음
vectorized multi-head attention을 위해 모든 행렬곱을 einsum에 넣고 optimize="optimal"로 matrix chain 곱 알고리즘을 써서 성능을 올려보았음, 실제로 일반 벡터화 구현 대비 2배 정도 빨라지긴 했으나 놀랍게도 루프 방식 순진구현이 더 빠름, 이유가 궁금한 사람은 코드를 참고 바람, einsum 내부의 cache coherency가 더 개선될 여지가 있다고 추정함
Hacker News 의견