Okay, I found something that seems to do the trick for this particular
problem. Instead of just checking whether the input to __getitem__ is an
int, I also check the number of dimensions to make sure we are indexing
within the full cube, and not some sub-index of the cube:
if self.ndim is 3 and is
Hi all,
I have a subclass of ndarray which is built using using a stack of images.
Rather than store the image header information separately, I overrode
__getitem__ so that when the user indexes into the image cube a single image
a different object type (which includes the header information) is r
On Wed, Aug 17, 2011 at 11:54 AM, Benjamin Root wrote:
> On Sat, Aug 13, 2011 at 7:17 PM, Mark Wiebe wrote:
>
>> On Thu, Aug 11, 2011 at 1:37 PM, Benjamin Root wrote:
>>
>>> On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote:
>>>
2011/8/11 Benjamin Root
>
>
> On Th
On Sat, Aug 13, 2011 at 7:17 PM, Mark Wiebe wrote:
> On Thu, Aug 11, 2011 at 1:37 PM, Benjamin Root wrote:
>
>> On Thu, Aug 11, 2011 at 10:33 AM, Olivier Delalleau wrote:
>>
>>> 2011/8/11 Benjamin Root
>>>
On Thu, Aug 11, 2011 at 8:37 AM, Olivier Delalleau wrote:
> Maybe
Great! It looks like it is in fact working as desired:
In [4]: cube.shape
Out[4]: (5, 4096, 4096)
In [5]: slice = cube[0]
In [6]: cube[0,1000,1000]
Out[6]: 618
In [7]: slice[1000,1000]
Out[7]: 618
In [8]: slice[1000,1000] = 123
In [9]: cube[0, 1000,1000]
Out[9]: 123
I didn't know about the .
On Wed, Aug 17, 2011 at 9:04 AM, Keith Hughitt wrote:
>
> Also, when subclassing ndarray and calling obj = data.view(cls) for an
> ndarray "data", does this copy the data into the new object by value or
> reference? The method which extracts the 2d slice actually returns a
> subclass of ndarray cr
The 2d arrays are read in using another library (PyFITS), so I probably
won't be able to control that too much, otherwise that sounds like exactly
what I need.
I'm actually overriding the indexing operation so that the user gets back an
ndarray subclass when they do "cube[0]":
def __getitem__
Right now you allocate new memory only when creating your 3d array. When you
do "x = cube[0]" this creates a view that does not allocate more memory.
If your 2d arrays were created independently, I don't think you can avoid
this.
If you have some control on the way your original 2D arrays are crea
Hi all,
I have a method which builds a single 3d ndarray from several
equal-dimension 2d ndarrays, and another method which extracts the original
2d ndarrays back out from the 3d one.
The way I'm doing this right now is pretty simple, e.g.:
cube = np.asarray([arr1, arr2,...])
...
x = cube[0]
I
On Wed, Apr 13, 2011 at 8:50 AM, John Hunter wrote:
> On Sat, Jan 15, 2011 at 7:28 AM, Ralf Gommers
> wrote:
>> I've opened http://projects.scipy.org/numpy/ticket/1713 so this doesn't get
>> lost.
>
> Just wanted to bump this -- bug still exists in numpy HEAD 2.0.0.dev-fe3852f
Just wanted to men
10 matches
Mail list logo
