[MATRIX-SIG] A proposal (LONG) - "reverse of take" revisited

[Edward C. Jones]

P.S.Craig@durham.ac.uk wrote:

> I have decided to stick my neck out and try to bring a
> little order to the discussion about extending NumPy's
> indexing that has been going on over the last week or so.
...

I would like to see block capability added to NumPy. Memory management,
numerical analysis, image processing, computer vision, and signal
processing all need blocks. Examples include transposing large matrices,
zooming or shrinking images, quadtrees, and wavelets.

The most useful current capability of this sort is "reduceat". The
manual says:

|ufunc.reduceat(a, indices, axis=0)                               
|
|   This is a weird function, and most people should just ignore it. It  
|   will reduce a to each of the given indices so that as new size along
|   the given axis will be the same as the length of indices.

This function is not weird. It is natural, powerful and useful. It
reduces each block to one value.

Something like the following are needed (all defined recursively):

* A slice that does not make a copy, so I can modify a part of an image.
* Efficiently view a big array as an array of blocks (each an array
itself) and vice versa.
* Convert an array of arrays to and from a big array.
* The ability to extract, insert, and manipulate sub-blocks of blocks.
For example, consider an interlaced image as an array of blocks, each
with two rows. Construct a pair of new images containing the even and
odd rows. Process these two images separately and recombine them.

Please don't make changes in Python or NumPy indexing schemes without
consider blocks and their users.

What is the best way to put blocks into NumPy?

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________