Re: [Numpy-discussion] Numpy x Matlab: some synthetic benchmarks

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

On Jan 18, 2006, at 6:21 PM, Fernando Perez wrote:

> Perry Greenfield wrote:
>> It's not a new idea. I raised it some time ago and I don't think it 
>> was
>
> I wasn't claiming authorship, sorry if it sounded like that :)  In 
> fact, I remember specifically talking with you about this at scipy'03, 
> in the context of small array performance issues for the 
> at-the-time-nascent numarray, and I'm sure similar things have been 
> done many times before.  I've had it floating in my head since I first 
> saw blitz, back in 2001, and blitz probably got it from...  There's 
> nothing really new under the sun ;)
>
Really :-). I remember that conversation and wondered if it had 
something to do with that. (And I remember Paul Dubois talking to me 
about similar ideas).  I think it is worth trying (and has been I see, 
though I would have expected perhaps even a greater speed improvement; 
somehow I think it should not take a lot of time if you don't need all 
the type, shape and striding flexibility). It just needs someone to do 
it.

>> new then either. I have to believe that if you allowed only Float64  
>> (and perhaps a complex variant) and used other restrictions then it  
>> would be much faster for small arrays. One would think it would be 
>> much  easier to implement than Numeric/numarray/numpy... I've always 
>> thought  that those looking for really fast small array performance 
>> would be  better served by something like this. But you'd really have 
>> to fight  off feature creep. ("This almost meets my needs. If it 
>> could only do  xxx")
>
> Couldn't that last issue be well dealt with by the fact that today's 
> numpy is fairly subclassing-friendly? (which, if I remember correctly, 
> wasn't quite the case with at least old Numeric).

Does that help? You aren't talking about the fast array subclassing 
numpy are you? I'm not  sure what you mean here.

Perry