python - Will results of numpy.as_strided depend on input dtype? -
will results of numpy.lib.stride_tricks.as_strided
depend on dtype of numpy array?
this question arises definition of .strides
, is
tuple of bytes step in each dimension when traversing array.
take following function i've used in other questions here. takes 1d or 2d array , creates overlapping windows of length window
. result 1 dimension greater input.
def rwindows(a, window): if a.ndim == 1: = a.reshape(-1, 1) shape = a.shape[0] - window + 1, window, a.shape[-1] strides = (a.strides[0],) + a.strides windows = np.lib.stride_tricks.as_strided(a, shape=shape, strides=strides) return np.squeeze(windows) # examples # rwindows(np.arange(5), window=2) # rwindows(np.arange(20).reshape((5,4)), window=2)
because of definition of strides , because, instance, otherwise equivalent arrays of dtype float32
, float64
have different strides, ever blow rwindows
function above?
i've tried test it's been in non-exhaustive way , looking answer (1) explains whether disclaimer/warning function doc has i'm asking here , (2) explains why or why not otherwise-equivalent arrays different dtypes & strides yield different results in above.
no, warning as_strided
2 issues not related size of data , more result writing resulting view.
- first, there no protection assure
view = as_strided(a . . . )
only points memory ina
. why there deliberate preparation work done before callingas_strided
. if algorithm off, can haveview
point memory not ina
, , may indeed addressed garbage, other variables, or operating system. if write view, data can lost, misplaced, corrupted . . . or crash computer.
for specific example, how safe depends lot on inputs you're using. you've set strides
a.strides
dynamic. may want assert
dtype
of a
isn't weird object
.
if you're sure always have 2-d a
larger window
, fine algorithm, can assert
make sure. if not, may want make sure as_strided
output works n-d a
arrays. instance:
shape = a.shape[0] - window + 1, window, a.shape[-1]
should be
shape = (a.shape[0] - window + 1, window) + a.shape[1:]
in order accept n-d input. probably never problem far referencing bad memory, current shape
reference wrong data in a
if had more dimensions.
- second, view created references same data blocks multiple times. if parallel write view (through
view = foo
orbar( . . ., out = view)
), results can unpredictable , not expect.
that said, if afraid of problems , don't need write as_strided
view (as don't convolution applications commonly used), can set writable = false
, prevent both problems if strides
and/or shape
incorrect.
edit: pointed out @hpaulj, in addition 2 problems, if view
makes copy (like .flatten()
or fancy indexing large chunk of it), can cause memoryerror
.
Comments
Post a Comment