[Numpy-discussion] question about optimizing

[Charles R Harris]

On Sat, May 17, 2008 at 1:45 PM, Charles R Harris <charlesr.harris@gmail.com>
wrote:

>
>
> On Sat, May 17, 2008 at 1:18 PM, Anne Archibald <peridot.faceted@gmail.com>
> wrote:
>
>> 2008/5/17 Brian Blais <bblais@bryant.edu>:
>>
>> > at least for me, that was the motivation.  I am trying to build a
>> simulation
>> > framework for part of the brain, which requires connected layers of
>> nodes.
>> >  A layer is either a 1D or 2D structure of nodes, with each node a
>> > relatively complex beast.  Rather than reinvent the indexing (1D, 2D,
>> > slicing, etc...), I just inherited from ndarray.  I thought, after the
>> fact,
>> > that some numpy functions on arrays would help speed up the code, which
>> > consists mostly of calling an update function on all nodes, passing each
>> > them an input vector.  I wasn't sure if there would be any speed up for
>> > this, compared to
>> > for n in self.flat:
>> >    n.update(input_vector)
>> > From the response, the answer seems to be no, and that I should stick
>> with
>> > the python loops for clarity.  But also, the words of Anne Archibald,
>> makes
>> > me think that I have made a bad choice by inheriting from ndarray,
>> although
>> > I am not sure what a convenient alternative would be.
>>
>> Well, it doesn't exist yet, but a handy tool would be a factory
>> function "ArrayOf"; you would pass it a class, and it would produce a
>> subclass of ndarray designed to contain that class.
>
>
> Subclasses should generally be avoided unless they satisfy the "is a"
> criterion, which I don't think a matrix stack does. That is to say, a
> subclass should behave as an ndarray in *all* ways except for added
> functionality. All we want is an item type with dimensions.
>

Base classes also tend to have limited functionality that will be common to
all derived types. The object type in Python has only a few methods and
attributes:

In [4]: dir(object)
Out[4]:
['__class__',
 '__delattr__',
 '__doc__',
 '__getattribute__',
 '__hash__',
 '__init__',
 '__new__',
 '__reduce__',
 '__reduce_ex__',
 '__repr__',
 '__setattr__',
 '__str__']

And overloading any of these is likely to cause trouble.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080517/63e95544/attachment.html