On 8/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > > On 8/29/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > > > > Charles R Harris wrote: > > > What *should* the resize method do? It looks like > > > it is equivalent to assigning a shape tuple to a.shape, > > > > No, that's what reshape does. > > > No, reshape returns a view and the view doesn't own its data. Totally > different behavior in this context. > > > so why do we need it? > > > > resize() will change the SIZE of the array (number of elements), where > > reshape() will only change the shape, but not the number of elements. > > The fact that the size is changing is why it won't work if if doesn't > > own the data. > > > According to the documentation, the resize method changes the array > inplace. How can it be inplace if the number of elements changes? >
It sounds like you and Chris are talking past each other on a matter of terminology. At a C-level, it's obviously not (necessarily) in place, since the array may get realloced as you surmise below. However, at the Python level, the change is in fact in place, in the same sense that appending to a Python list operates in-place, even though under the covers memory may get realloced there as well. > Admittedly, it *will* change the size, but that is not consistent with the > documentation. I suspect it reallocates memory and (hopefully) frees the > old, but then that is what the documentation should say because it explains > why the data must be owned -- a condition violated in some cases as > demonstrated above. I am working on documentation and that is why I am > raising these questions. There seem to be some inconsistencies that need > clarification and/or fixing. > The main inconsistency I see above is that resize appears to only require ownership of the data if in fact the number of items changes. I don't think that's actually a bug, but I don't like it much; I would prefer that resize be strict and always require ownership. However, I'm fairly certain that there are people that prefer "friendliness" over consistency, so I wouldn't be surprised to get some pushback on changing that. -- . __ . |-\ . . [EMAIL PROTECTED]
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion