At 5:17 PM -0400 2004-10-22, Todd Miller wrote:
On Fri, 2004-10-22 at 14:17, Russell E Owen wrote:
I agree. Numarray is already confusing enough without identically named functions and methods that do different things.
True enough. This'll be fixed.
Great!
(nElements and size are another pet peeve, with size used in several places and nElements appearing exactly once. Though I am grateful to whoever added size as a workalike for nElements; formerly you had to know what kind of array you had before you knew how to find out how many elements it had.)
I'm not sure what you mean here. When I grepped, I got 52 hits for nelements() in the numarray source, let alone what users have done with it. Right now, IMHO, it's not clearly broken and there are bigger fish to fry.
Since you ask... I'm counting the number of implementations in the public interface of the numarray package. There are four implementations of size (including the numarray array method, which is simply a synonym for nelements), but only one implementation of nelements. When I started using numarray, the following was true: * numarray had a function named size. * numarray.ma had the same function * numarray.ma arrays had method size * All of these worked the same way: size(array, axis=None) size returns the number of elements in an array or along the specified axis. BUT numarray arrays had no method size. Instead there was a method nelements, which did the same thing as size, but had no "axis" argument. This was very confusing, and I got tripped up badly because I was trying to count array elements and was using both "normal" numarray arrays and masked arrays. I filed PR 934514 and some kind soul patched the problem by making size a synonym for nelements. There is a bit of residual mess because the new size does not have the axis argument. And then there's the historical clutter of two ways to do the same thing, but presumably one just lives with that. Though it seems a bit strange to me not to deprecate nelements and stop using it internally. -- Russell