From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91240 invoked by alias); 4 Nov 2015 23:06:18 -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 91231 invoked by uid 89); 4 Nov 2015 23:06:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: proofpoint5.lanl.gov Received: from proofpoint5.lanl.gov (HELO proofpoint5.lanl.gov) (204.121.3.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 04 Nov 2015 23:06:16 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id tA4N6DJi015911 for ; Wed, 4 Nov 2015 16:06:13 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id C8C5113A513F for ; Wed, 4 Nov 2015 16:06:13 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Received: from manticore.lanl.gov (manticore.lanl.gov [130.55.124.157]) by mailrelay1.lanl.gov (Postfix) with ESMTP id A7AAA13A5135 for ; Wed, 4 Nov 2015 16:06:13 -0700 (MST) Message-ID: <563A8F65.1040706@lanl.gov> Date: Wed, 04 Nov 2015 23:06:00 -0000 From: Gerard Jungman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release 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> In-Reply-To: <563A6C15.7080102@colorado.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21,1.0.33,0.0.0000 definitions=2015-11-04_14:2015-11-04,2015-11-04,1970-01-01 signatures=0 X-SW-Source: 2015-q4/txt/msg00003.txt.bz2 On 11/04/2015 01:35 PM, Patrick Alken wrote: > Hi Gerard, > > So if I understand correctly, restricting the discussion to > gsl_vector for now, the issue is that in order for users to use the > various GSL vector routines, they must first call gsl_vector_alloc, > and then copy their data into the gsl_vector object, and then use the > routine they want. > > The better approach would be to define their vector array however > they wish, and then get a gsl_vector_view of that array (without > needing any GSL allocation routines), and then directly use the > routine they want. This is of course currently possible with > gsl_vector_view_array, however it would be better to pass the view > object directly to the GSL function, rather than having to pass > &view.vector ? Yes. One of these is required. But it's more than making the interfaces nicer. The current design is upside-down. The view types are actually implemented in terms of the alloced types. Strange, but true. This leads to all sorts of bad design elements, like the 'owner' data element in the vectors. Why do vectors need an 'owner' member? Apparently because they might actually be part of a view and not own their data. This is just wrong. Some users have reported on the mailing list that they get around this mess by jamming a pointer and size into a gsl_vector, setting 'owner' to zero, and getting on with life. For these workarounds, the 'owner' flag is a lucky circumstance. But this is clearly nuts. This need should be filled by explicit support from the types and not by hackery. As part of a fix, the types should have much cleaner and orthogonal relationships, and the interfaces should not carry this implied dependency on the semantics of the heap-allocated types, whether people can get around it by hackery or not. > So to summarize: > 1. All GSL routines which currently take gsl_vector* arguments, > should be modified to accept gsl_vector_view* instead But with a correctly designed thinner view type. > 2. gsl_vector_view should be redesigned to be cleaner/simpler <- I'm > still not completely clear on what this would look like Make the views the "fundamental" types and have the fat types essentially inherit from (or export an interface for) the non-const view types. > 3. Ditto for gsl_matrix And, while we are at it, multi-arrays too, which could be provided with not much extra effort. Though, of course, no current GSL interfaces depend on such things, since they don't exist in the main code base yet. Finally, the implementation of the fat container types is also brain-damaged because of the "composition by indirection" design. For example, gsl_vector and gsl_matrix carry pointers to gsl_block. This leads to an unnecessary chain of allocations, as has also been discussed recently on the mailing list. The compositions, to the extent they are needed, should be more value-centric. Avoid these annoying indirections. And the construction idiom for the fat containers should be more value-centric. Returning gsl_vector indirectly at construction is yet another unnecessary indirection and heap allocation. This obviously requires a complete re-design. But these aspects of the work are not hard. It's not hard to get these things right, it just requires some free time and a willingness to break all the interfaces that currently touch the containers. -- G. Jungman