Interesting problem. numpy.take(lut, ...)
gets transformed into lut.take(...)
whose source can be looked at here:
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/item_selection.c#L28
I believe the exception is thrown at line 105:
obj = (PyArrayObject *)PyArray_FromArray(out, dtype, flags);
if (obj == NULL) {
goto fail;
}
where in your case out
is arr
but dtype
is the one of lut
, i.e. uint8
. So it tries to cast arr
to uint8
, which fails. I have to say that I'm not sure why it needs to do that, just pointing out it does... For some reason take
seems to assume you want as the output array to have the same dtype
as lut
.
By the way, in many cases the call to PyArray_FromArray
will actually create a new array and the replacement will not be in place. This is the case for example if you call take
with mode='raise'
(the default, and what happens in your examples), or whenever lut.dtype != arr.dtype
. Well, at least it should, and I can't explain why, when you cast lut
to int32
the output array remains uint16
! This is a mystery to me - maybe it has something to do with the NPY_ARRAY_UPDATEIFCOPY flag (see also here).
Bottom line:
- the behavior of numpy is indeed difficult to understand... Maybe someone else will provide some insight into why it does what it does
- I would not try to process
arr
in place - it seems that a new array is created under the hood in most cases anyway. I'd simply go witharr = lut.take(arr)
- which by the way will eventually free half of the memory previously used byarr
.