From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5235 invoked by alias); 7 Jan 2010 01:50:20 -0000 Received: (qmail 5102 invoked by uid 22791); 7 Jan 2010 01:50:16 -0000 X-SWARE-Spam-Status: No, hits=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jan 2010 01:50:11 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id o071o99X007115 for ; Wed, 6 Jan 2010 18:50:09 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 9717E15DB8C5 for ; Wed, 6 Jan 2010 18:50:09 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 946B27D0053 for ; Wed, 6 Jan 2010 18:50:09 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 8223C7D0051 for ; Wed, 6 Jan 2010 18:50:09 -0700 (MST) Subject: Re: gsl container designs From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: References: <1259110486.3028.69.camel@manticore.lanl.gov> <4B4477B8.50305@iki.fi> Content-Type: text/plain Date: Thu, 07 Jan 2010 01:50:00 -0000 Message-Id: <1262829020.27244.361.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-01-06_15:2010-01-05,2010-01-06,2010-01-06 signatures=0 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: 2010-q1/txt/msg00005.txt.bz2 On Wed, 2010-01-06 at 10:47 -0500, Robert G. Brown wrote: First, I want to say that I agree with everything you say. These are exactly the problems that we need to solve. > IMO the primary reason for "fixing" vector/matrix objects in the GSL is > to enable the single vector that represents the actual data in the > object to be presented to the user in a matrix-intuitive way, even at > some cost in code efficiency (and to try to minimize that cost or > provide further benefits to counterbalance it by enabling efficient > linear algebra routines to be matched to it, for example). In fact, I don't even see a need to sacrifice efficiency. I think this goal is directly achievable at essentially optimal efficiency. My attitude about C is that it is all about lining up the bytes. A good C design is just some syntactic layer on top of a rudimentary layer, where-in you are careful to line up all the bytes. After that, optimal efficiency is pretty much automatic. C is very friendly, once you are careful to line everything up. I hope you see my small but non-vacuous technical meaning. > What I want is extremely simple: > > * A way to construct/allocate a matrix of arbitrary dimension (out to some > (un)reasonable max, e.g. 10 Check. > but I want to be able to use it > just like m[i][j][k]...[r][s] when all is said and done. This is the only part which I wonder about. I thought about this before and came to the conclusion that it is not easy to get right. Probably possible, but very tricky. The most annoying aspect of this is that these little problems are trivial in C++. But maybe just beyond the capability of C. > * The specific dimension bounds need to be user specified. If I want to > make a 6 dimensional triple triangular array to hold e.g. 3j symbols, I > don't want to have to allocate a rectangular array most of which is > empty wasted space. See the earlier comment by Tuomo Keskitalo, about banded/packed storage. Not something I have thought about yet, but probably not hard. > * Access to the underlying actual data vector (non-opaque, in other > words) so it can be passed to e.g. ODE solvers and the like that can > only be sensibly written in a general way for a vector. Check. > My problem in this regard with the GSL is that so far, the matrix and > vector constructs are pretty much useless -- they are far away from the > standard way one usually does this sort of thing in C using pointers or > just allocating a vector or matrix. I find them useless as well, for exactly these reasons. > One of the ADVANTAGES of C is that it permits one to work pointer magic > to improve the readability (and sometimes execution efficiency) of code. > Opaque types and set/get calls are dark evil in both regards. Right. The layer which defines the "types" should be essentially syntactic, just there to make it easier to organize/understand your code. The underlying implementation should be a brutally simple pile of bytes, and it should be visible. -- G. Jungman