From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8670 invoked by alias); 20 Sep 2009 13:23:07 -0000 Received: (qmail 8660 invoked by uid 22791); 20 Sep 2009 13:23:06 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail.phy.duke.edu (HELO mail.phy.duke.edu) (152.3.182.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Sep 2009 13:23:02 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id 251E5BEE17; Sun, 20 Sep 2009 09:22:10 -0400 (EDT) Received: from mail.phy.duke.edu ([127.0.0.1]) by localhost (mail.phy.duke.edu [127.0.0.1]) (amavisd-new, port 10026) with LMTP id SCibdQUxqCZA; Sun, 20 Sep 2009 09:22:10 -0400 (EDT) Received: from lilith.rgb.private.net (client212-5.dsl.intrex.net [209.42.212.5]) by mail.phy.duke.edu (Postfix) with ESMTP id 7DAC7BEDA5; Sun, 20 Sep 2009 09:22:09 -0400 (EDT) Date: Sun, 20 Sep 2009 13:23:00 -0000 From: "Robert G. Brown" To: Tuomo Keskitalo cc: GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap (one man's view) In-Reply-To: <4AB5F77F.8020104@iki.fi> Message-ID: References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@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> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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/msg00058.txt.bz2 On Sun, 20 Sep 2009, Tuomo Keskitalo wrote: > I agree that use of other libraries and even other languages with GSL should > be made as easy as possible. Data structures with dimension > 1 should be > explicit about the data being stored as "column-major" or "row-major". I agree completely, and I further strongly suggest that 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; c) that the data should be stored/packed using the same convention that C already uses to pack e.g. v[i], m[i][j] declared data types. Yes, this leaves one with the perpetual conflict with e.g. fortran libraries, but GSL is a C library, not a fortran library, and it should conform to the common usages and standards of C and not try to interpolate to make fortran programmers comfortable at the expense of C programmers. My reasons for each suggestion are straightforward. a) permits many routines, e.g. ODE solvers, to be written for general purpose tensors by letting them trivially directly access the vector data associated with the tensor; b) allows the caller to use meaningful tensor notation to evaluate functional forms throughout their code instead of using get or set utilities to access particular elements of the tensor; c) makes the code portable in critical ways -- it would be silly to have for(i=0;i > -- > Tuomo.Keskitalo@iki.fi > http://iki.fi/tuomo.keskitalo > Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu