Re: new double precision data structure?

[James Bergstra <bergstrj@iro.umontreal.ca>]

I really like the idea of a GSL n-dimensional array, because it would
make it much easier to interoperate with numpy, scipy, and the other
tools which are developed in that community.

Compared to numpy's ndarray structure, there are only a few
differences with your proposal.

Firstly, the ndarray untyped.  The data is in a void * pointer or a
char * pointer or something, and there is an extra enum-valued field
that indicates what sort of elements make up the data.  For example, 0
might mean int8, 1 might mean uint8, 2 might mean int32, 10 might mean
float32, 11 float64, 12 complex64, and so on.  There is support for
non-native elements like structs and objects too.  We wouldn't need
all of that flexibility in the GSL, but the technique might be useful
for allocating and passing around tensors of integers, floats, complex
numbers.

Secondly, there is no notion of a 'layout' in the ndarray, so I wonder
if it is necessary here?  When you explicitly store the strides for
traversing the tensor in each dimension... what is left for the
'layout' to specify?

Thirdly, the dimensions are logical things, not physical ones.  So
perhaps they belong in the view rather than the base block?  I think
the simple { size_t n_allocated; char * buf } structure is sufficient
for the base block.

Fourthly, if you take the dimensions out of the base block, then they
need to into the view as well... so the view would wind up looking
something like:

{
int ndim;
size_t * dims; /* the size of the tensor in each of `ndim` dimensions */
int * strides;  /*negative strides are very useful */
gsl_type_t type; /* something like gsl_float32, gsl_float64,
gsl_complex128, etc. */
void * data;  /* pointer into the underlying block, not necessarily
the beginning */
base_block * base;
int owner; /* True -> free the base with ourselves */
}

The biggest advantage of moving the dimensions from the base_block to
the view that it allows in-place reshaping and transposing of views,
which would be awkward otherwise.

Macros / functions can make it convenient to get a properly-casted
pointer to the underlying data (returning NULL when the type being
asked for doesn't match the type of the data).  For example
gsl_view_data_float32(view).

James Bergstra
-- 
http://www-etud.iro.umontreal.ca/~bergstrj


On Sun, Sep 27, 2009 at 4:03 AM, Tuomo Keskitalo <Tuomo.Keskitalo@iki.fi> wrote:
> On 09/16/2009 03:49 AM, Gerard Jungman wrote:
>
>> It smells like a view, and indeed it is. But it is a notion of
>> view which is more central to the design than the current one.
>> Everything should be a view.
>
> I think we really need to sort the data structure out now.
>
> I'm not sure what you have in mind, but to get some discussion going on,
> I've attached an (incomplete and untested) idea for a general n-dimensional
> double precision data structure. Is this anything like what you pictured?
>
> I'd like to hear people's comments on this. Would something like this be of
> use? Feel free to give your full critique.
>
> --
> Tuomo.Keskitalo@iki.fi
> http://iki.fi/tuomo.keskitalo
>