From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122722 invoked by alias); 4 Nov 2015 23:16:19 -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 122708 invoked by uid 89); 4 Nov 2015 23:16:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: na01-bn1-obe.outbound.protection.outlook.com Received: from mail-bn1on0141.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 04 Nov 2015 23:16:16 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=patrick.alken@colorado.edu; Received: from palken-co-ll.ngdc.noaa.gov (140.172.179.43) by DM2PR0301MB0909.namprd03.prod.outlook.com (10.160.217.14) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 23:16:12 +0000 Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release To: 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> From: Patrick Alken Message-ID: <563A91B7.90904@colorado.edu> Date: Wed, 04 Nov 2015 23:16: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: <563A8F65.1040706@lanl.gov> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CY1PR0601CA0002.namprd06.prod.outlook.com (25.160.162.12) To DM2PR0301MB0909.namprd03.prod.outlook.com (25.160.217.14) X-Microsoft-Exchange-Diagnostics: 1;DM2PR0301MB0909;2:X5Cimoj+cYO3erMppURypYAqKMDnt6eXKW8j5RXZZ1qDZJwGQmP4Ef9TniWl0nQM+ofib5jSiPA+zsO+Hg67dh9dXKaA5NBpKAWKdpF9cfPIxlz8yNGTMQBnHZ5SMkIr6Scdi6SBUl01UP1GxXrm020PDS3zAP8YQb5wLo6wqD4=;3:khE0LpIODgmbC7u2ZHSTU0Im2PKWEbjmvCBePZeMZGhxaPv69OKT5gWYfOHpQhfsCA4sAbx9EVT/Ufsnb6opWe2XLj5AtGkBf9IF+yf0/WlG9T+8XhfyZPlRimAZO/QUgiD9UjnwdBOb7Trf7NNXKQ==;25:cihYJfq/J0hbre4TJn/B5nWvCPh8IIjrd+Uxb4bg04cokOHNYsZCOEWQxWwDu+oFGgMsa3uHS3BzKG3r0pcbmfLVC6K/cO0Nja+PuY/aQMfyBipD9IpdHMUocPtawjfhmBXO0pMX16Kfqct8fp1HMwck8s2FtvfElFhB0Lrfw4VLbwhmW/T0tbcZ2htee9MYr8gxbFhuKSnShHa8xmzmxaIMglfZekL+loxla3JYy/3PgnioQpof2VL6wgEIDSvjdAcJMEnMPWyYWUPLRdPF+Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0909; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:DM2PR0301MB0909;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0909; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0301MB0909;4:85bY1l/cdVYqulXaVAsMPD9lnSQmKnAIR6wKN97QqJsUV8pCgC5BXRbFBWf8JYR8HkioHLPGv8U3eJog//giPYr3iE8G4d8PmXHWesVx1DW++FZDxslEsg+aVrS1xXU1uvWjJz3N5+X2OBhcGxPqaFpMqC19iSwHZ/S6AMrnqlxlwWkQbxi7wdYgMF0I9hLQNo6VHGMBHvcsN5FSVWZn5YFScYOdc8eIiuY/KC1OqkKjqSGzuJDBGw7aAlxd5DJ/gdpUEKXJJFa+xhhjQmTI8YFgRDAUGb6qXMFw91G5uMozT7kILp5katmJiBRb0SdjPWETiu8f3FqbM565hyDia6Ia94HbfNNN1WjkPAJcJ1Pzc73qGFOLlTcbz+iWBBX3 X-Forefront-PRVS: 0750463DC9 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(189002)(199003)(65806001)(65956001)(89122001)(66066001)(105586002)(42186005)(106356001)(93886004)(50466002)(47776003)(77096005)(5001960100002)(5004730100002)(5007970100001)(40100003)(97736004)(2351001)(189998001)(36756003)(81156007)(450100001)(92566002)(122386002)(83506001)(230700001)(107886002)(5008740100001)(87976001)(64126003)(4001350100001)(65816999)(50986999)(90282001)(75432002)(76176999)(33656002)(88552001)(2950100001)(23676002)(110136002)(54356999)(101416001);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0301MB0909;H:palken-co-ll.ngdc.noaa.gov;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Received-SPF: None (protection.outlook.com: colorado.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAzMDFNQjA5MDk7MjM6SG5SU0JZaEU3MU1HUk9sTXRTM09XK3FR?= =?utf-8?B?OVlRYVNYdlV1YXI3a1JFT1kvc1RpNmR1N01aMWUzUVppM2NQWE5mcFRtZUti?= =?utf-8?B?SjVzNjZjUzZIQ3JONHFaeENHdE10Wm82clRZeUsxbkphR1dpWjVFclUzQ0Zx?= =?utf-8?B?c3JGTXJlSDZkQXYrOFVjWkpaWXJpMG5NbGtTWThoaEVueXEzOTJjZGY3QUVP?= =?utf-8?B?eFlwS2JYaGpDTnVobWVjdFlHaU9uT29KVjQ1clhkaTV6V2Z0N1U3SWl5Nkcv?= =?utf-8?B?c0xocnBQSWZiR0wyWmxoSE5rSFBiQ2JjUkNRR3VpWlU2K3A2ekx1RmZyYlkr?= =?utf-8?B?bjdQY2d3VTJvejczSDhDSURFMUxwUUFCU2tUVUhPRVRiUFJPUG9ZZlN5S29a?= =?utf-8?B?MkdNR3RERXg3S3lPMVFtMjBlT2pMaE9vUDc4Q3NqSGxqK2NuRXM2T2VrTzNU?= =?utf-8?B?QjgzeUZWQm9lNnVkZzNseHBOcjM3dUpxUHAxa0FOK1V6Sk1xRzVFRDVTN2Fk?= =?utf-8?B?Rnc2VW5kWWRsaC96RE5YL3ZLT2Y4L0JYcm9sMFNCYlcyYlp6VG4xdlFSNzVz?= =?utf-8?B?TDl3WHJ3NE1yWUVmaVZSMWYweW9wOGxnVUxUZU5COFhldTUvRjdrVmJHQ29h?= =?utf-8?B?ZEJPdThXQ2pmNXRjQ1hIQjdRMW9rMjN1aStUYlRhYzRzTG1LWit2N1NDVDhG?= =?utf-8?B?NjB5dkJpSWl2MEFsM0dHSG1JYVdWNVRid1I4NmhETCtMZ3owNXJndlFyOTJj?= =?utf-8?B?QWlLTXBISUxOY2k5aUxBNXhERHRaSXpHU25uZzJQNDRQRU14Ym1UbC9pVUpq?= =?utf-8?B?VUd3WEtyRlNCeiswZDNmNTUyWFB6SjB4VVpMcy91V2xXTHBtOXJhM1ZBTnpV?= =?utf-8?B?d0JmNFlsMUpZZWRvQ056bktNb01xcnRMR3dnMDdBRk1BYmFIUUNLbUkxNVJT?= =?utf-8?B?Nm1jSTNORUN3bUxHSmFwZitFaUZxTzdoTDNjRGtNZGJsaGo0S3FZTXlyLzFa?= =?utf-8?B?WjYvN0dnbzVRVS9TNmc5ckphUGlYeCtSRlQyWGVwZnJvTjl2REJwdERma0Jq?= =?utf-8?B?V2FvSlRDQ1ppenVwV0hKYjFKdml2QXlFNkdrT2xNZEZ0Z3hQWlRiMVc2VTJL?= =?utf-8?B?SlM1aUxsT2ZxbmQvVXN2am0zSkhpVXdjWE00MkJHSVJoM042ZUI4VkI0azFW?= =?utf-8?B?OWJzVU9KMlphblpvMUdPZjFhMXg5TUwxdGVReEZvZ1U1OWlIclBFbFJyZWx5?= =?utf-8?B?SmZxbmRCOTdLSU1SdTA1S3V2ZXdaejZYMVFRSWdaV0pHRzBkcE9CcFB4YlNU?= =?utf-8?B?U1UvcjRlTDJMcWRGSnRpdFkxR3ptMGtkdEZLUlZYZ1dSSm9CWDJTTDd6ZXUy?= =?utf-8?B?d0h0T3hNQWVKZUUzb3JRcDBBTXVTclNUYnJpdGcrLzJiZGxhUG5pTmdWMEV3?= =?utf-8?B?R3JaaVRkeGM2ZE01QTVsTnlLRWplWU16KytmWUJnV1hmSkVvZHUwKytUbnJp?= =?utf-8?B?UVQ5NWFVYTdjVUVpTkFVMDR6YlFIT0FTSTN1SkczelgxYnZtbzRRKzRidlpQ?= =?utf-8?B?eGJySkM2VE1GVlhNeHRLd1BVa1BFMVJSU1FqcFB0cld1SU5jSmF0bWF6NlNV?= =?utf-8?B?MG9kTjZiNDA3YVJNWnc0RVoyNEJBVG5iYit1VUF6aWRsSTFyUTN0TGtpNXQv?= =?utf-8?Q?8yWvzaNpABf8C1doLJ94=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0301MB0909;5:GBmFF+M6P78SEpAiKmZeJruFlK13WdCY7SYxsy65wjb781dGkiNvzT1P9/enAlTlupO3VQ5kR5AGxTgggyg42zZdtyc+DBDwPd2yIA3oNZkxXxNuNG+C7ew4C5p2RqfXLl19MOxk8Nhb1cL23QqglA==;24:mThVFLE0JryqD+J1bHyH9NUywE8RIV7eCZF+lFGToZt3MyqqOd9mZX37vR7mHNIn0he/XANunJMfB/8H6Ni9ShTCIbh4/y79CI9uTkqbIMg=;20:gR8rw2o+xHiVu1D/gj8vx9xtbsoe5oKAFav581KMe/kZFWPLKgPGUgwhq39TMpPYQXdND1UKMpEbe8jKOy35NA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: colorado.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2015 23:16:12.3774 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0909 X-SW-Source: 2015-q4/txt/msg00004.txt.bz2 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 On 11/04/2015 04:06 PM, Gerard Jungman wrote: > 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 >