From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gsl-discuss-return-5486-listarch-gsl-discuss=sources.redhat.com@sourceware.org>
Received: (qmail 21709 invoked by alias); 7 Sep 2009 15:10:25 -0000
Received: (qmail 21686 invoked by uid 22791); 7 Sep 2009 15:10:23 -0000
X-SWARE-Spam-Status: No, hits=-0.6 required=5.0
	tests=AWL,BAYES_50,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 15:10:17 +0000
Date: Mon, 07 Sep 2009 15:10:00 -0000
Message-ID: <m3fxazosvn.wl%bjg@network-theory.co.uk>
From: Brian Gough <bjg@gnu.org>
To: GSL Discuss Mailing List <gsl-discuss@sourceware.org>
Subject: Re: GSL 2.0 roadmap (one man's view)
In-Reply-To: <1251414939.23092.82.camel@manticore.lanl.gov>
References: <48E25CA9.6080306@iki.fi>
	<490DE4BD.7070907@iki.fi>
	<m3y700znqd.wl%bjg@network-theory.co.uk>
	<497B00F6.2080400@iki.fi>
	<m38woqp3je.wl%bjg@network-theory.co.uk>
	<498727E5.6080407@iki.fi>
	<49AA9DB5.6030908@iki.fi>
	<49FB01D1.30000@iki.fi>
	<m3ljp7amw3.wl%bjg@network-theory.co.uk>
	<4A7ADFDC.9080408@iki.fi>
	<m3r5v4527i.wl%bjg@network-theory.co.uk>
	<1251414774.23092.80.camel@manticore.lanl.gov>
	<1251414939.23092.82.camel@manticore.lanl.gov>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Message-Mac: 92574a93da5c82ec19344a309f8e5422
Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gsl-discuss.sourceware.org>
List-Subscribe: <mailto:gsl-discuss-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gsl-discuss/>
List-Post: <mailto:gsl-discuss@sourceware.org>
List-Help: <mailto:gsl-discuss-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gsl-discuss-owner@sourceware.org
X-SW-Source: 2009-q3/txt/msg00031.txt.bz2

>    As a kind of apology for this state of affairs, the functions attempt
>    to estimate errors, using heuristic and sometimes ill-defined methods.
>    This turns out to be a poor apology, since it tends to gum-up the
>    works for the whole sublibrary, eating performance and occupying
>    a large piece of intellectual real estate.
> 
>    The error estimation code must, at the least, be factored out. More
>    to the point, is should likely be discarded in the main line of
>    development. Other notions of error control should be investigated.

I have found the error estimates to be pretty useful when debugging,
and they are only a small extra cost.

Some of the hypergeometric functions are difficult to understand in
places.  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.