From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12727 invoked by alias); 16 Sep 2009 00:47:52 -0000 Received: (qmail 12718 invoked by uid 22791); 16 Sep 2009 00:47:51 -0000 X-SWARE-Spam-Status: No, hits=-10.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 00:47:48 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id n8G0lkG4003363 for ; Tue, 15 Sep 2009 18:47:46 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 861BE165126 for ; Tue, 15 Sep 2009 18:47:46 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 84D787D009D for ; Tue, 15 Sep 2009 18:47:46 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 7559E7D009C for ; Tue, 15 Sep 2009 18:47:46 -0600 (MDT) Subject: Re: GSL 2.0 roadmap (one man's view) From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: 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> Content-Type: text/plain Date: Wed, 16 Sep 2009 00:47:00 -0000 Message-Id: <1253062217.23092.973.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-09-15_11:2009-09-01,2009-09-15,2009-09-15 signatures=0 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/msg00049.txt.bz2 On Mon, 2009-09-07 at 16:09 +0100, Brian Gough wrote: > > As I mentioned in previous emails, there isn't a feasible general > solution for LAPACK with the column-major matrix restriction, due to > the combinatorial explosion of cases that must be handled. I don't understand "combinatorial explosion". LAPACK only handles column-major, so it can only be fed column-major. If you want to use it, all your data structures are born column-major, or you convert them as needed. We need to simply allow for the existence of the column-major world. It's only fair. And it's a simple variation to encode in any of our data structures. Every serious C++ vector/matrix library allows for both column-major and row-major layout, because they know people need it. Templates, or other gymnastics, are not required. You just have to decide that you want it. > We could adopt FLAME, which is a much more general framework, C-based > and faster than LAPACK. I really think this is a better way to go > than LAPACK. Unfortunately it doesn't have so many routines at the > moment. For me, the string "LAPACK" stands for any existing code base that people will want/need to use. FLAME is just another "LAPACK" for these purposes. There is nothing for us to "adopt". It's the end user who "adopts" a package to use. We just have to make it easy for them to adopt whatever they like. And if FLAME, or any other library, uses data structures which make it hard for people to talk to or translate to, then they have made a mistake. On Mon, 2009-09-07 at 14:21 -0400, Robert G. Brown wrote: > I've never been that fond of LAPACK anyway -- it's not like it is easy > to use and perfectly intuitive anyway. I know. But it works. And people want it. It's crazy to ignore it. -- G. Jungman