From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3159 invoked by alias); 16 Sep 2009 02:48:00 -0000 Received: (qmail 3146 invoked by uid 22791); 16 Sep 2009 02:47:59 -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; Wed, 16 Sep 2009 02:47:54 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id AA28ABEDF6; Tue, 15 Sep 2009 22:47:30 -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 JVLjNSufBIio; Tue, 15 Sep 2009 22:47:30 -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 F1C7FBEDF5; Tue, 15 Sep 2009 22:47:29 -0400 (EDT) Date: Wed, 16 Sep 2009 02:48:00 -0000 From: "Robert G. Brown" To: Gerard Jungman cc: GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap (one man's view) In-Reply-To: <1253062147.23092.970.camel@manticore.lanl.gov> 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> <1253062147.23092.970.camel@manticore.lanl.gov> 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/msg00050.txt.bz2 On Tue, 15 Sep 2009, Gerard Jungman wrote: > On Mon, 2009-09-07 at 16:06 +0100, Brian Gough wrote: >> At Thu, 27 Aug 2009 17:15:39 -0600, >> Gerard Jungman wrote: >>> The important notion of slicing is (partially) implemented in GSL >>> in terms of the "view" concept. One can construct submatrices as >>> views of given matrices, change the stride of vector data by >>> creating vector views, etc. But there are clear flaws in the >>> design. The design does not express the obvious idea that >>> a "view" is itself a "thing", simply because the view classes >>> do not have an inheritance relationship to the main classes. >> >> I agree that the scheme is not as elegant as it could be in other >> languages. The view types are forced by the nature of const in C -- >> it's not possible to place the views and vectors/matrices on an equal >> footing and preserve constness, unfortunately. If there is a way >> round that, I'm not aware of it. > >> Originally a view was essentially a vector with another name, but >> there was no barrier to writing expressions which discarded constness >> without any complaint from the compiler. To prevent that in C, the >> type had to be "wrapped" in a struct which is why one has to write >> &view.vector or &view.matrix to access it. > > > I really don't understand this. In my head, I can see a solution > which has nothing to do with const-ness issues. I think it would > just work. I could type it in and we could look at it. It definitely > involves changing the way vector and matrix are done, but I don't > think it would be a big hairy deal. > > > On Mon, 2009-09-07 at 14:21 -0400, Robert G. Brown wrote: >> >> The biggest issue would/will probably be rationalizing the views of >> vector and matrix so they are sufficiently portable and easy to e.g. >> pass in and out of ODE solvers and everything else consistently. > > This is right to the point. It's exactly what I'm getting at. > There is just something brain-damaged about the way it is done now. Bless you. And remember, it would be really nice if there was a certain scalability in dimension. The world doesn't stop at *a, **b -- there is ***c, ****d, etc where a number of sciences need at least through six dimensions and back when we were kicking this around on list three or four years ago somebody (doing relativity?) said that they use eight or nine. Tensors, especially tensors that don't "have" to be square, are very useful. In my own code, I have used at least ****d tensors that were allocated as a single data block and the indices repacked into the tensor and then cast to a type. You can bass the data block to an ODE solver as a vector, but you can write the actual deriv routine using the tensor pointer, which means that it is actually intelligible and debuggable without four layers of index arithmetic wrapped up on some sort of macro or horrorshow code. I don't remember if I mentioned it before, but multidimensional integration (on spaces that may or may not be flat of dimension greater than or equal to two) would be a lovely addition to the next release as well. There's C++ code out there (Hint) and I did a port of one of the Hint routines at one time, but e.g. integration over a sphere of functions with Y_lm's in them is another extremely common problem in math and physics, and spherical domains in spherical coordinates do not map well into nested one-D quadrature routines... rgb > > -- > G. Jungman > > 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