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.

  1. first, there no protection assure view = as_strided(a . . . ) only points memory in a. why there deliberate preparation work done before calling as_strided. if algorithm off, can have view point memory not in a, , 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.

  1. second, view created references same data blocks multiple times. if parallel write view (through view = foo or bar( . . ., 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

Popular posts from this blog

android - InAppBilling registering BroadcastReceiver in AndroidManifest -

python Tkinter Capturing keyboard events save as one single string -

sql server - Why does Linq-to-SQL add unnecessary COUNT()? -