From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30172 invoked by alias); 28 Sep 2009 08:44:07 -0000 Received: (qmail 6913 invoked by uid 22791); 27 Sep 2009 16:34:12 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4ABF1C3C.6070801@iki.fi> References: <48E25CA9.6080306@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> <1253062179.23092.971.camel@manticore.lanl.gov> <4ABF1C3C.6070801@iki.fi> Date: Mon, 28 Sep 2009 08:44:00 -0000 Message-ID: <7f1eaee30909270934v7ae7f4a6u6cbf9d16b099978b@mail.gmail.com> Subject: Re: new double precision data structure? From: James Bergstra To: Tuomo Keskitalo Cc: Gerard Jungman , GSL Discuss Mailing List Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00068.txt.bz2 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 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 >