From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44797 invoked by alias); 7 Nov 2015 14:09:16 -0000 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 Received: (qmail 44785 invoked by uid 89); 7 Nov 2015 14:09:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.2 X-HELO: johndlamb.net Received: from srv210-24.hosting24.com (HELO johndlamb.net) (212.1.210.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 07 Nov 2015 14:09:14 +0000 Received: from host86-186-118-66.range86-186.btcentralplus.com ([86.186.118.66]:33572 helo=[192.168.1.64]) by srv48.hosting24.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1Zv4B4-001rfx-Vj for gsl-discuss@sourceware.org; Sat, 07 Nov 2015 09:09:12 -0500 Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release To: gsl-discuss@sourceware.org References: <56293649.8010009@colorado.edu> <562BA530.7090508@johndlamb.net> <562E432D.9050002@colorado.edu> <56367D54.1040302@johndlamb.net> <56391F62.2030103@lanl.gov> <563A6C15.7080102@colorado.edu> <563A8F65.1040706@lanl.gov> <563A91B7.90904@colorado.edu> <563AB455.1020706@lanl.gov> <563ADDF5.1020206@colorado.edu> From: John D Lamb Message-ID: <563E0604.6080802@johndlamb.net> Date: Sat, 07 Nov 2015 14:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563ADDF5.1020206@colorado.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: srv48.hosting24.com: authenticated_id: j.d.lamb@johndlamb.net X-SW-Source: 2015-q4/txt/msg00006.txt.bz2 On 05/11/15 04:41, Patrick Alken wrote: > I agree that stuff is very confusing. I also wonder how much of it is > needed. In my work I've only ever used the double and complex versions > of gsl_vector/gsl_matrix. Most of the routines in GSL only work with > double vectors, with a few extended to complex double (linalg,eigen for > example). > > Do we really need gsl_vector's for int/short/uint/long/etc? I have used gsl_vector_long on occasion. > On 11/04/2015 06:43 PM, Gerard Jungman wrote: >> On 11/04/2015 04:16 PM, Patrick Alken wrote: >>> I think this is a good idea. Would you be able/willing to design a >>> new gsl_vector_view structure? Even something very preliminary which >>> we could iterate a bit to get it to a nice mature status. I, or >>> someone else, could then run with it and begin the tedious work of >>> converting all the existing interfaces. >>> >>> Patrick >> >> If anybody can think of a better way to do the generalizations, >> besides the current preprocessor implementation, that would be >> great. I have nothing against the preprocessor, but the current >> framework makes it nearly impossible to actually read the code. Ruby? Python? In the absence of C++ templates I usually use one or other. Python is likely more readable to C programmers. >> The current impl is like traits classes, but where the traits >> are all defined in a very rudimentary way in "templates_on.h". >> It is impossible to tell what traits are available, which ones >> are required, and how the separate traits are associated with >> the basic types at the point where the macros are invoked. I’m happy to help if someone can suggest a basic workable design. I can certainly change the alloc functions to use a pool allocator internally. And, since I mostly use C++, I can see the logic of initialising vector structs. But I can’t think of a good design that won’t break a lot of user code. One of the features of the GSL is that you can’t alloc a vector of size 0 without writing a custom allocator. It would be easy to change gsl_vector_alloc. But I can’t even think how to do that and guarantee not to break user code. -- John D Lamb