From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54625 invoked by alias); 6 Jul 2015 20:13:26 -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 54615 invoked by uid 89); 6 Jul 2015 20:13:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: rs201622.rs.hosteurope.de Received: from familie-sitte.org (HELO rs201622.rs.hosteurope.de) (176.28.53.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 06 Jul 2015 20:13:22 +0000 Received: from localhost (localhost [127.0.0.1]) by rs201622.rs.hosteurope.de (Postfix) with ESMTP id 65F2D2FB6 for ; Mon, 6 Jul 2015 22:13:19 +0200 (CEST) X-Spam-Score: -1.1 Received: from rs201622.rs.hosteurope.de ([127.0.0.1]) by localhost (rs201622.rs.hosteurope.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWtScx1fQPqo for ; Mon, 6 Jul 2015 22:13:19 +0200 (CEST) Received: from meerkat.local (cpe-70-112-90-217.austin.res.rr.com [70.112.90.217]) by rs201622.rs.hosteurope.de (Postfix) with ESMTPSA id AE0512FB5 for ; Mon, 6 Jul 2015 22:13:18 +0200 (CEST) Message-ID: <559AE15C.40904@familie-sitte.org> Date: Mon, 06 Jul 2015 20:13:00 -0000 From: Matthias Sitte User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: new interface for simulated annealing References: <559AC9EA.2080005@familie-sitte.org> In-Reply-To: <559AC9EA.2080005@familie-sitte.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-q3/txt/msg00002.txt.bz2 On 7/6/15 1:33 PM, Matthias Sitte wrote: > It's not yet fully > finished, but I'd like to hear your thoughts on it in general, and how to > proceed if you want to incorporate it into GSL at some point (in terms of > requirements etc). Reading up on the GSL design manual [1], I guess that implementing a "standalone package" version on top of the current GSL library would be the best way to develop it. If the new interface turns out to be stable and decent, GSL maintainer could try to (but would not need to) merge it into the then-stable GSL? Matthias [1] https://www.gnu.org/software/gsl/design/gsl-design.html#SEC3