[Numpy-discussion] Further comments
Perry Greenfield
perry at stsci.edu
Sat Dec 28 13:54:02 EST 2002
Edward Jones writes:
>
> Should the variable "type" be used in numarray? It is an important
> function in Python.
>
We pondered this for a while. Yes, it conflicts with the built
in function (and so that function is aliased within the numarray
code to a different name). Do you see this causing problems for
you? Normally there is no conflict in using it as a keyword name
for function or method arguments, but if you can show practical
cases where it is a problem, we may reconsider. It seemed to us
that type was the best name for the keyword, particularly since
we were discouraging people from thinging of typecodes.
> ---------------------------------------
>
> There needs to be a function or method that returns the number of
> elements in an array.
>
> def Elements(array):
> """Number of elements in an array.
>
> This version is slow.
> """
> return numarray.multiply.reduce(array.shape)
>
> ---------------------------------------
>
I don't disagree. It would be nice to have a consensus for what the
function name (and perhaps an array attribute?) should be. I believe
IDL uses nelements (which I find more suggestive than elements), but
perhaps others have better names.
> I write code using both PIL and numarray. PIL uses strings for modes and
> numarray uses (optionally) strings as typecodes. This causes problems.
> One fix is to emit a DeprecationWarning when string typecodes are used.
> Two functions are needed: StringTypeWarningOn and StringTypeWarningOff.
> The default should be to ignore this warning.
>
I'm not sure I understand. Can you give me an example of problem
code or usage? It sounds like you are trying to test the types
of PIL and numarray objects in a generic sense. But I'd understand
better if you could show an example.
>
> The following function is useful for downsizing arrays. I suggest that
> it should be a ufunc method. This is how I have used reduceat in Numeric.
>
> def blockreduce(array, blocksizes, ufunc):
> """Apply ufunc.reduce to blocks in an array."""
> dims = len(array.shape)
> if type(blocksizes) is IntType:
> blocksizes = dims * [blocksizes]
> if len(blocksizes) != dims:
> raise TypeError, 'blocksizes must be same length as shape'
> for i in range(dims):
> if array.shape[i] % blocksizes[i] != 0:
> raise ValueError, 'blocksizes must exactly divide ' \
> 'the corresponding array dimension'
> for i in range(dims):
> array = array.copy()
> newshape = (array.shape[0] / blocksizes[i], blocksizes[i]) + \
> array.shape[1:]
> array.shape = newshape
> array = ufunc.reduce(array, 1)
> dims = len(array.shape)
> # (0,1,2,3) --> (1,2,3,0)
> perm = tuple(range(1, dims)) + (0,)
> array = numarray.transpose(array, perm)
> return array
>
We certainly have frequent need for a binning function (i.e.,
the equivalent of a blockreduce for add). Do others see this
as a generally useful extension for all binary ufuncs?
(As a side comment, the requirement that the dimensions be
evenly divisible is often a pain; one question is to ask whether
this must be a requirement or not, or whether there is a way to
disable this requirement, i.e., permit the last block to be smaller
than usual?)
Thanks, Perry Greenfield
More information about the NumPy-Discussion
mailing list