This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: containers tentative design summary


On Tue, 2009-10-06 at 13:37 +0100, Jonathan Underwood wrote:
> 
> I'm not sure if I fully follow this, but I wonder if the numpy concept
> of "broadcasting" is useful here? More info:
> 
> http://docs.scipy.org/doc/numpy/reference/ufuncs.html#broadcasting

Ok. This could be useful. I will study it and see if it helps.
If it turns out to be too dynamic an idea for efficient C, then
I'm not sure if we can do anything with it. But who knows...


> In general, I can't help thinking that it would be a great advantage
> if compatibility with the underlying data structures used in numpy was
> achieved during this redesign (numpy is mostly implemented in C and is
> BSD licensed).

I'm looking at this right now:

 /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h

Certainly it has the same basic functionality, with a shape described
by dimensions and strides in each index place. Some of the other stuff,
like byte-order worries, I imagine we have to ignore. That is presumably
beyond the scope of GSL.

Can we be precise about the meaning of "compatibility"? This is the
kind of thing we need to discuss. I would definitely like to see
GSL play better with others.

There are other tools out there as well. I don't follow the
history of Numeric and NumPy and ScientificPython, blah blah.
It all looks a little disorganized to me. People who know
about these things, and have opinions, should tell us what
we should be doing.

--
G. Jungman



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]