From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10165 invoked by alias); 16 Sep 2009 00:44:36 -0000 Received: (qmail 10157 invoked by uid 22791); 16 Sep 2009 00:44:35 -0000 X-SWARE-Spam-Status: No, hits=-9.9 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:44:31 +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 n8G0iUQa001037 for ; Tue, 15 Sep 2009 18:44:30 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 21EE8165126 for ; Tue, 15 Sep 2009 18:44:30 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 207EF7D009D for ; Tue, 15 Sep 2009 18:44:30 -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 10C6D7D009C for ; Tue, 15 Sep 2009 18:44:30 -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:44:00 -0000 Message-Id: <1253062021.23092.954.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/msg00044.txt.bz2 regarding error estimates in the special functions: On Mon, 2009-09-07 at 13:13 +0100, Brian Gough wrote: > > I have found the error estimates to be pretty useful when debugging, > and they are only a small extra cost. It's not about cycles. Nobody is counting cycles (yet). It's about the intellectual cost of having all that junk in there. It takes up valuable real estate, makes it very difficult for third party contributors to work with, and it is not based on any rational methodology. There is a long discussion about this on the mailing list, from some years ago. It arose again recently. See the archived thread starting with: http://sourceware.org/ml/gsl-discuss/2004-q3/msg00059.html Now about cycles. Whether or not the cycle count shows a real performance issue on current hardware is an open question. I'm sure it depends on the details, and probably on hardware in some cases. But whether or not it is real, there is perceived problem. See the comments in the above thread. Perceived problems are real problems, when you are trying to expand the user base. > Some of the hypergeometric functions are difficult to understand in > places. I wrote them, and I find them nearly impossible to understand. And I never use them; I would rather spend time finding a more reliable solution in any specific circumstance. Eventually they will be scrapped, or at least relegated to some closet in the library where we store messy things. As I have said before, having those functions living right next door to gold-plated Bessel function implementations is incongruous. This is a _real_ problem because it clouds the issue of reliability for the whole module. > Here it would be good to have an explicit higher-level > version of the C implementation, for example in Maxima, that one could > test against and understand more easily. Maybe. If somebody wanted to do that. But it's never that simple. That would only address some fraction of the possible problems; the details would remain too different. A combination of methods is needed. The first real step would be to refactor so that all the commonality in methods is better exposed. There are too many places where the same continued fraction method or series summation method is being applied, with only slight variation. But I digress. -- G. Jungman