RE: [Numpy-discussion] Further comments

[Perry G. <pe...@st...>]

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