From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116292 invoked by alias); 4 Nov 2015 20:35:45 -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 116276 invoked by uid 89); 4 Nov 2015 20:35:44 -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-bn1bon0116.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (157.56.111.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 04 Nov 2015 20:35:42 +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 BN3PR0301MB0897.namprd03.prod.outlook.com (10.160.156.14) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 20:35:38 +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> From: Patrick Alken Message-ID: <563A6C15.7080102@colorado.edu> Date: Wed, 04 Nov 2015 20:35: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: <56391F62.2030103@lanl.gov> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DM3PR18CA0010.namprd18.prod.outlook.com (25.164.243.20) To BN3PR0301MB0897.namprd03.prod.outlook.com (25.160.156.14) X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB0897;2:j5KiV6I4w2uB60IY3njJ2nQ1DZUFtm0BHjmdVLBO87ZGprY7BcAHWRS05T+pwnvrHr0biyiiJTrOAvxLhT04pCz9YE0VrMC85h0CnYtL1frpz/R59fd6YYmz2cd16PvmNPtaqYOlrZJ6+S44jGbPHygKqeremiB9XQ664grHscc=;3:w6yscSO3ZUVFRdbQPWJUsfNcKZfoNCLDWK9T7gVIdV/5tFji3BvJ1iyFDQAgnBw04D/NgnMWMxj+BKivhzHsVf2DHFg9OtZILhyVwogxZEpPk7iifM+zxG9eHiJEN9eQeixuwQ64Ai/rd2wjL37LKw==;25:HJxUna8sWG8aR9PkHbctbmiIuSN//9mIExWv9rljZ9G9ehhadogiKJg+2YD08k9iAKOLL7Yeh2zY7xoMx7+NgIRvDRa7bLz9kDanw5SDZKm7zVvhxbhxju0ASNo6GQ5CMwhqq1fO4zAnqbtllgnvYHkvx4WdoeDCrjfWlTdy3MLGWn9zUthk7WI7bKVv6GPHPNOcQMjCi0nMSQPpTu7kdFzTxLIl1tg5zW8XxUJholgeITnhb1GsPCrKvf7D3X67FMpN694HKOB8B2Hx2XFSdQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0897; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046);SRVR:BN3PR0301MB0897;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0897; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB0897;4:NKyRsXHj2sP57AfB4c9NKH0UnecLoDGTqtEcfUcZryV8xreiAbtfgYzyQhDnRYTTwhiKJ+A/t4fymj3KqHJj7Bwex1v/vU+TzYWRu8KLFE0N/CRinnNwHja9Q+yjMj1MBprIKafyaXUCWfbWT1b2bUYcJi/DX+RZLvee+Vnj5KHRvdlq3u+lr8Acpci48CO54fjS5frLrhyzWg9uT3kBaZy6qnO3/lcwzO9NE81QSwZ3GjUDNjB9+qARy8Lr9QVLJE4sZ8Lsqssr9mLffOk4FzSzDJ/6+KqPyqF34TeU/8qHD67Ea5PZ4I93T22CCd0rK5SnNAD3cyKEenuTHcZH61Oswm1FouS9RanJxOZ1zyzvfBygZLrHMH44pXhP0M2i X-Forefront-PRVS: 0750463DC9 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(199003)(189002)(19580395003)(93886004)(66066001)(107886002)(88552001)(81156007)(83506001)(2950100001)(4001350100001)(89122001)(36756003)(97736004)(110136002)(15975445007)(59896002)(33656002)(90282001)(2351001)(5007970100001)(23676002)(5004730100002)(87976001)(450100001)(54356999)(64126003)(5008740100001)(92566002)(65816999)(76176999)(80316001)(101416001)(75432002)(50466002)(65956001)(87266999)(77096005)(5001960100002)(106356001)(40100003)(105586002)(50986999)(47776003)(189998001)(42186005)(122386002)(65806001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0301MB0897;H:palken-co-ll.ngdc.noaa.gov;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: colorado.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAzMDFNQjA4OTc7MjM6K29pLzhjd2RQWVVwakExczd4dWxiN3Y1?= =?utf-8?B?QjFLbVBHQllhRzlKTm5EalEyb1hKRys5MmtoWDZaSFB4Z1dxRG9Xa0EyK3RL?= =?utf-8?B?UXlQNzhEdlc4RWNNbHMrcDBxMW8wZ2lIekpWakRmNGU2UDZLT1Z5Y1VsQ3lG?= =?utf-8?B?OVo4Tlg4QXlEOThCSXpCbVB2cVd4MUQwaW8zNlJjcFJHemNXalk1T0YvS0VX?= =?utf-8?B?d0tTeTRxWXBOMy92ZEhiQkhMKytId0Y1UE5yZVJ6azlaNUpvTVJTMjVRNis5?= =?utf-8?B?WDJFaTI5QURib1NzWGRnWWI5eXFFNGU3SUxaQ240dVJUU28zenR6OUFzbnVI?= =?utf-8?B?RVZmMVY5T09EOE41NWZ6ZW1sS1ZnS1N4MHpSZDU3QUhyQ1BTSlZoWmlpZHJx?= =?utf-8?B?cC8zT3pVa3Fra1ZkSkJQMWJ6YktwNUtTcnp5bXRkYVMyTGcyT1RFRExkS3J3?= =?utf-8?B?M0VaOFloYkJmRWhQUndhaVQyRXY0WGcrR3pWNEcwTGpGaFl3SzlOSTVENXh6?= =?utf-8?B?a25MY1V6empzbWRKR1A1SnYvRlFvcUtxaFhzV09UZHBPN3dpQ05BWXF1Rm45?= =?utf-8?B?Si9kTHI3Rm5WSTE0VXovcGNndHVoZlplODVWSGxEeWxHaVRoeVFsdW0xNnJv?= =?utf-8?B?aHFHYm1USlhHbzdWZFdxbEE5eVMrL3FTMktGdU9wWmRYV2Q5SUhvaDJZbWx3?= =?utf-8?B?VTdxRHZIbUNqRnZ1WXNURkZPU2ZOT0FoeUlwdmJ6Snd2eXNJM29rdkx5SFRN?= =?utf-8?B?Z01kcUhlcFNjQmFKNXVKZVhNUUJaT0oxRnowUUh5KzJEUHdrSnVpZXYvdUdu?= =?utf-8?B?aC9QSUlEdHREK3ozaStiZ1ZCMm9aRk1sTmlHZitqOFB6d0QxN1lPMThkTXd3?= =?utf-8?B?N0lxNEQ1MVBsaitYVVdTRTY1YkRnRG9pUUVLVnExREpza3haYjd2R1NVWWEv?= =?utf-8?B?dDJRTy9rdkxnaldnTDdIOCt2RGx5cXY3RlRjOXVqU1lxRFZySGRrVEh3RE5Y?= =?utf-8?B?WFBBVmFEQlJEdUExeU4zcytyV1N4bXNCUmlnc1FlMmlBZ2EvYkZGVW50TmVN?= =?utf-8?B?c1F3ZXduN29JekJaYk5TSXVJcldqV0RacXZpdjAwS0ZGREdib1NzcFZpOEJW?= =?utf-8?B?RkJ4WDhHNUJzbStxUGxMb2xoNFU5emMzclorcEVSZlpLRHdPRmRkV1hrbzdm?= =?utf-8?B?b3QvOTB4UFpFM1QxSUNXd2ZObGJJbkplK09MUEUrbkdDbEJ5ejVPUmVjYmYy?= =?utf-8?B?OTh6TWJYNU5SeEV2SDByWHc1V2xiVjFSdEhyWkRKVS9IQUxZZnpvUzNMTjln?= =?utf-8?B?VTdBbUE4NHcxTWxvbFdLT0U4cXhjU2h5MnhMOEdrcldBWHlhamo5ZTNlbmhl?= =?utf-8?B?aldJT0V3VjJrMWFJVDVacEsxa2EwQ0VqOUQ4M1g4WHl4eVIyYzNLZ29ybFNm?= =?utf-8?B?M0IvUDdUeHR2WFJqeVNQdUhaaXhRcjlCQ1h6ekdGaUkrdGJXSFlBOTg0OFNK?= =?utf-8?B?MWRiNHFQQWVpNFJKSjA0aTA0ZVNxMUVLdFAzdHRjcC9EdFNWMU8wOFVpdHZo?= =?utf-8?B?cStjWHVYU2VDTEVndTFYRHJEbU5pcGVQUlBDek9zbXdnQUdMTnhqd1QzajVK?= =?utf-8?B?aUFEbDFkRUd0Y2xDQzZ6eUdGT2pFeklHaWpKN3BCNXE2M3pqSERhdjloT1E0?= =?utf-8?B?QXp2TEFiOWIvaWw4eE5mL1JTcVhOaTJUVWZmT20wV3VWeWplOXp3VmY3UzNY?= =?utf-8?B?SkxpWStyK1FFSmJXbjZxdzFRZThlS3JHbnJUZ2VnQmRVMndTdk5uNFNqOE5G?= =?utf-8?B?WVhLMHJqMlA1bmUrV0dzanVady96UVl4UGhBWWV5ajJ6TDRMUT09?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB0897;5:OZjPCo4wmAeKzvj81RUm+4q0y5yqF6nEzHsjyzn4IdYhDusZF0WapQKxoHsi8OAG+5tVrw6n02zGhpQnIdzykyZ9kk7RZ78SCe0sLMQusp6Ht1H+H6BaV8fgbXX6/e+dt9kg1VIMRDP9f70KKUiqWQ==;24:l8uchoSPAkVtTLX28zvCeheTPgyO6OyvnjJlY5TRFrSlHqBMltzy1v+UihRUldmnHcgxc1UbfLX8+k7GMMlq8G6K3SrExi7m40Wnc4PP4OI=;20:U4YTf+PcYn1fJkwz90pGl3GeuTKlqMLoy1gtq9pPV3gitGyIiEjVVct3IFS0ki3wWV4qvp0AR+wr0HulNkPpFw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: colorado.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2015 20:35:38.8764 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0897 X-SW-Source: 2015-q4/txt/msg00002.txt.bz2 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 ? So to summarize: 1. All GSL routines which currently take gsl_vector* arguments, should be modified to accept gsl_vector_view* instead 2. gsl_vector_view should be redesigned to be cleaner/simpler <- I'm still not completely clear on what this would look like 3. Ditto for gsl_matrix Is this a correct assessment of what you're saying? If so, in principle I completely agree it can be burdensome on the user to constantly have to pass &view.vector, &view.matrix all the time. It would be nice to simply pass 'view' instead. Patrick On 11/03/2015 01:56 PM, Gerard Jungman wrote: > > The problem with the GSL containers is that the allocation > strategy is hard-wired into the implementation. Adding > another allocation strategy is not the answer, it just > adds to the problem. > > Put another way, the real problem is that the GSL interfaces > are written in terms of gsl_vector and gsl_matrix objects, > which forces clients to carry along the allocation baggage > whenever they want to use a GSL interface. > > The interfaces (every function that currently takes a > const gsl_vector * for example) should be re-written in > terms of a view type which is independent of allocation > strategies. A view type should be basically a thin > wrapper over a pointer and a length for vectors. > For multi-array objects it would be a thin wrapper > over a pointer with an addressing/indexing interface. > > The current "view" types are brain-damaged because > they stand the design on its head. This is because > they were added as an afterthought to the existing > heap-allocated vector/matrix objects, at the time > when this was all being implemented. Badly done. > > At the implementation level, the other main problem > is the way the types are "composed" using indirections. > This is awful and leads to the multiple allocations and > other heap-centric lossage that has been discussed > recently. Both views and full-fledged containers > should be composed in a value-centric and > stack-friendly way. > > And preferably in a way that allows them to interoperate > and keep const-correctness. I believe this is all possible. > > -- > G. Jungman > > > On 11/01/2015 02:00 PM, John D Lamb wrote: >> On 26/10/15 15:13, Patrick Alken wrote: >>>> Yes. I’d be happy to look at redesign of the GSL containers. What’s >>>> needed? >>>> >>> >>> There was a discussion on gsl-discuss some time back, see: >>> >>> https://www.sourceware.org/ml/gsl-discuss/2014-q2/ >>> >>> Gerard may have already done some work on this, or have some ideas on a >>> good starting point, so I suggest getting in touch with him too (cc'd). >> >> >> I’d forgotten the detail of that discussion. >> >> I can think of a way to change the gsl block/vector/matrix alloc >> functions to be more efficient. In essence it is a pool allocator. >> It would keep a record, for each power k of two up to some limit n, >> of the number of blocks allocated for sizes 2^k to 2^{k+1} together >> with a capacity (also a power of two) for blocks of that range. These >> would form linked lists of allocated and unallocated blocks. Given a >> request for a new block, if an unallocated one was available, it >> would be allocated. Otherwise the capacity would be doubled. When a >> block is freed, memory is only deallocated if no more than a quarter >> of capacity is used or if no blocks are used. >> >> This idea needs more input. >> >> I can’t think of a good way to create gsl_vectors and the like in >> stack memory. Of course, it is always possible to create a struct and >> initialise it. >> >> I also don’t know of a good, easy solution to the problem of constness. >> >