On Mon, Apr 12, 2010 at 4:19 PM, Travis Oliphant <oliphant@enthought.com>wrote:
>> On Apr 11, 2010, at 4:17 PM, Sebastian Walter wrote:
>> >
> > Ermm, the reply above is quite poor, sorry about that.
> > What I meant to say is the following:
> >
> > If there is going to be a discussion about creating a pure C numpy
> > library I'd like to join ;)
>> Great. I would really like to get the discussion going. In an
> ideal world we can finish any kind of significant re-factoring in time
> for SciPy this year. It actually feels like the kind of thing that
> can motivate NumPy 2.0 a bit better.
>> It sounds to me like nobody will be opposed as long as there is
> continuity to the project and current code still works without
> disruption (i.e. the current C-API for Python extensions is available).
>> I am interested in re-factoring in such a way to create minimal impact
> on current NumPy C-API users, but improve maintainability going
> forward and the ability for other projects to use NumPy.
>>My own thoughts were to have a lowlevel 'loop' library that worked with
strided memory, and an intermediate level above that for buffer objects.
Numpy ufuncs would be a level above that and implement policy type things
like casting, kinds, etc.
Then there is the lowlevel c-library for the functions. I don't think we
should aim at duplicating commonly available functions like sin and exp, but
rather that subset that are sometimes unavailable. In particular, I would
like to get away from having to use double versions of functions instead of
type specific versions.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100412/67b3992d/attachment.html