Re: [Numpy-discussion] ObjectArray

[Todd M. <jm...@st...>]

On Fri, 2004-06-11 at 10:53, Colin J. Williams wrote:
> Todd,
> 
> I'm trying out objects.py from the CVS as of June 11, with PROTOTYPE=
> 1
> 
> Suggestions and comments based on that.
> 
> 1.  change the order in ObjectsArray so the __init__ becomes:
>                 def __init__(self, objects=None, shape=None,
> rank=None):
>      The thinking is that, in the absence of others, objects is the
> argument most likely to be specified.

I think this can go either way.  For people that care,  there are
already array() and fromlist().  Subclasses can override the order.  Am
I missing something?

> 2.  add a check in __init__ to ensure that the shape is in fact
> shape-like.

Right now it raises a TypeError, and although it's ugly, it does at
least trap the error and give a clue in the right direction.

> 3.  real doc strings would be helpful.  Currently, the doc strings are
> monopolized by the doctest stuff, 
>      which was  not  the original intent of doc strings.

True enough.  Maybe for 1.1.

> 4.  I wonder about the need for both rank and shape.  NumArray gets
> along fine with just shape.

This is a new feature, and is useful in the context of object arrays
where a sequence object is an ambiguous thing:  should the sequence be
seen as containing elements of an object array, or itself an element of
the object array.  rank lets you specify the rank of the resulting
object array explicitly.  It is also computed implicitly if not
specified based on the first object which doesn't match the type of the
original sequence.  This is new for 1.0.

> 5.  It is assumed that objects (in __init__) is a sequence, but no
> check to make sure that it is.

Actually, for 1.0 I don't even think it has to be a sequence anymore. 
It's possible to make a rank-0 object array.

> 6.  _byteorder is specified for NumArray, but not for ObjectArray,
> this upsets a utility which 
>      looks at array   characteristics.

_byteorder is a private attribute which doesn't make sense for
ObjectArray.  Add exception handling to the utility if it must be used
with ObjectArrays.

> 7.  How is an ObjectArray better than a nested list of objects?  It
> seems to provide speedier access
>      to object pointers for larger n.  It may offer the opportunity 
> to present data in a more organized
>      tabular manner.  Dictionaries are better, in that they provide
> access by means of an arbitrary key, 
>      for the cost of hashing.
> 
>      NumArray appears to offer storage saving, in addition to the
> above, but not here.
> 
>      Am I missing something?  

ObjectArrays can be indexed, manipulated, and printed like numarrays. 
ObjectArrays also work with object array ufuncs, so for instance, adding
two ObjectArrays together implicitly applies the add builtin to each
pair of elements.  These ufuncs even support reductions and
accumulations.  This *is* a good question,   but I still think
ObjectArrays are useful in some contexts.

Thanks for the feedback.

Regards,
Todd