Hi, On Tue, Jul 31, 2012 at 7:30 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Tue, Jul 31, 2012 at 4:57 PM, eat <e.antero.ta...@gmail.com> wrote: > > Hi, > > > > On Tue, Jul 31, 2012 at 6:43 PM, Nathaniel Smith <n...@pobox.com> wrote: > >> > >> On Tue, Jul 31, 2012 at 2:23 PM, eat <e.antero.ta...@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
