From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4605 invoked by alias); 20 Sep 2009 15:31:07 -0000 Received: (qmail 4596 invoked by uid 22791); 20 Sep 2009 15:31:05 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f225.google.com (HELO mail-fx0-f225.google.com) (209.85.220.225) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Sep 2009 15:31:01 +0000 Received: by fxm25 with SMTP id 25so1671184fxm.0 for ; Sun, 20 Sep 2009 08:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.36.207 with SMTP id u15mr3388248bkd.39.1253460659114; Sun, 20 Sep 2009 08:30:59 -0700 (PDT) In-Reply-To: References: <48E25CA9.6080306@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> <1253062087.23092.965.camel@manticore.lanl.gov> <4AB5F77F.8020104@iki.fi> From: Rhys Ulerich Date: Sun, 20 Sep 2009 15:31:00 -0000 Message-ID: <4a00655d0909200830j76902792pf5a9698611743f32@mail.gmail.com> Subject: Re: GSL 2.0 roadmap (one man's view) To: gsl-discuss@sourceware.org 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/msg00060.txt.bz2 > a) the actual data in any tensor form be stored in a single contiguous > vector whose address is available to the user and not hidden inside an > opaque data object; > b) the tensor itself be a **...*pointer, cast to the desired > type, packed with the offsets into this vector Given both (a) and (b) everyone pays storage overhead for indexing twice. The first time is to store the leading dimensions for (a)-like access, and the second time is to store the pointers-to-pointers for (b)-like access. Since (a) already exists today, if you want (b) it can be provided as a view. Your cost will be storage overhead for pointers-to-pointers, dereferencing delay, and potential cache misses if the pointers-to-pointers for (b)-like access are far away from (a)'s data. I think those that want (b) should have a view that accomplishes it, but that people using (a) only shouldn't pay for the overhead. I believe these are the reasons that both the C and Fortran numerics communities pretty consistently stay towards (a)-like storage under the covers. Also, to be fair to the current design, gsl_matrix and gsl_vector are structs, but they certainly aren't opaque. - Rhys