[Numpy-discussion] Just ignore me. That was an accidental send.

Travis Oliphant oliphant at ee.byu.edu
Fri Feb 4 10:47:45 EST 2005

Todd Miller wrote:

>Please ignore that last post.   It consists of unfinished thoughts which
>were sent accidentally.  Doing numarray isn't easy.
Unfinished or not, there were some good comments here, worth hearing. 

>>I think you've done a real service here,  bounding the cost of new-style
>>classes,  but I'm not convinced we have a bottom line,  at least not in
>>the sense of my own FUD about new style classes.  I'm not contesting the
>>technical direction you're taking with Numeric3 (I hope it works,  but
>>the details are up to you),  but I am contesting the idea that new style
>>classes do nothing but speed up object creation.
Yes, your point about subclassing new-types causing speed slow downs is 
a very valid one and that has not been tested at all.  But, for my 
purposes, I was just interested to know if allowing a record Array to 
subclass from Numeric3 would cause slow-downs to the rest of Numeric.   
It appears that this will not be the case.  Clearly any type that 
subclasses from Numeric3 might still have speed issues, but those were 
less of a concern for me, right now.

>>So,  I'd assert that unless you solve *that* problem,  using new style
>>classes and some form of inheritance,  saying that new style classes do
>>nothing but speed things up is stretching the truth.  To really disprove
>>the hidden costs in my FUD,  I'd want to see a C basetype and
>>inheritance by a Python subclass.
Sure.  But, my hope is that only RecordArrays would need to subclass in 
Python (or potentially in C).   These might incur some creation 
"slowdown" but it would be inconsequential to the rest of Numeric.

>>If you can pull it off and still cleanly support the features of
>>numarray,  it will be a triumph of KISS.  But that's not a given.
Clearly it's not a given, but I have high hopes.  I really think it can 
be done. 


More information about the NumPy-Discussion mailing list