[Numpy-discussion] array slicing questions

[eat]

Hi,

On Tue, Jul 31, 2012 at 7:30 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Jul 31, 2012 at 4:57 PM, eat <e.antero.tammi at gmail.com> wrote:
> > Hi,
> >
> > On Tue, Jul 31, 2012 at 6:43 PM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Tue, Jul 31, 2012 at 2:23 PM, eat <e.antero.tammi at gmail.com> wrote:
> >> > Apparently ast(.) does not return a view of the original matches
> rather
> >> > a
> >> > copy of size (n* (2* distance+ 1)), thus you may run out of memory.
> >>
> >> The problem isn't memory, it's that on 32-bit Python,
> >> np.prod(arr.shape) must be <2**32 (or maybe 2**31 -- something like
> >> that).
> >
> > I think this is what the traceback is indicating.
> >>
> >> Normally you wouldn't be creating such arrays anyway because
> >> they would be too big to fit into memory, so this problem isn't
> >> observed, but when you're using stride_tricks then it's very easy to
> >> create arrays that use only a small amount of memory but that have
> >> very large shapes.
> >
> > But in this specific case .nbytes attribute indicates that a huge amount
> of
> > memory is used. So I guess stride_tricks(.) is not returning a view.
>
> No, .nbytes is lying to you -- it just returns np.prod(arr.shape) *
> arr.dtype.itemsize. It isn't smart enough to realize that you have
> wacky strides that cause the same memory region to be referenced by
> many different array elements.
>
Aha, very good to know.

Thanks,
-eat

>
> -n
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120731/dc17ff33/attachment.html>