From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38202 invoked by alias); 23 Nov 2015 20:07: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 38181 invoked by uid 89); 23 Nov 2015 20:07:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: COL004-OMC2S13.hotmail.com Received: from col004-omc2s13.hotmail.com (HELO COL004-OMC2S13.hotmail.com) (65.55.34.87) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Mon, 23 Nov 2015 20:07:41 +0000 Received: from na01-bl2-obe.outbound.protection.outlook.com ([65.55.34.73]) by COL004-OMC2S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 23 Nov 2015 12:07:39 -0800 Received: from BLUPR16MB0196.namprd16.prod.outlook.com (10.162.233.158) by BLUPR16MB0193.namprd16.prod.outlook.com (10.162.233.155) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 20:07:37 +0000 Received: from BLUPR16MB0196.namprd16.prod.outlook.com ([10.162.233.158]) by BLUPR16MB0196.namprd16.prod.outlook.com ([10.162.233.158]) with mapi id 15.01.0331.019; Mon, 23 Nov 2015 20:07:37 +0000 From: Bill Maier To: "gsl-discuss@sourceware.org" Subject: Bug #45782 Date: Mon, 23 Nov 2015 20:07:00 -0000 Message-ID: authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=hotmail.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [lLvOs3Ec8SvBxgWBhAByfPJ3lzULI8gf] x-microsoft-exchange-diagnostics: 1;BLUPR16MB0193;23:miWonl+viqU9ZlByHWlU6fnUKDsY7jdMGLFwdU4kJ3KAyVO+gInkdlZZN+/qMEBnXGY8D/LNcX6CMrx7BeWgwmSybuejzxhuGJxtsqM4ZI+a7MQFSweiHd56WmValBVW2NUackEhnc/NwET4XC0mIRlzPUVQD0lOUpwU+fT5gDL6BkeNMOrdMDp91kqZtPHXjsotVKKnf88Sdwp1xcMA+A==;5:5OMJbZdX2ac7+NSaHN64Dfzwk2gend4tKxkKULQSXLkbtl58Do87mdO6QY5CrlYY2wlnJ7B/HQZAq/eR0a1yxvWvqv9soAKeIkNkoZOcDdCWn80MLD2RUnhV3ogosOakrMUNE+P1EjlLpvYCWy3QPw==;24:72kFd2/84gvTPb5CCVMh7dyEDr2iFuePapuM/chGAau4dxtqGv9FlxadRiEPBXsiJ9/IC17WXXHZ2sDAKx4pLv8THwiErCEIzKTKYAgF9O4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR16MB0193; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(81415001)(82015046);SRVR:BLUPR16MB0193;BCL:0;PCL:0;RULEID:;SRVR:BLUPR16MB0193; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM;SFS:(7070004)(98900002);DIR:OUT;SFP:1901;SCL:1;SRVR:BLUPR16MB0193;H:BLUPR16MB0196.namprd16.prod.outlook.com;FPR:;SPF:None;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sct-15-1-318-15-msonline-outlook-a6494.templateTenant X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 20:07:37.1016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR16MB0193 X-SW-Source: 2015-q4/txt/msg00013.txt.bz2 The actual implementation of this feature is rather straightforward. The function that numerically computes the Jacobian already has a parameter for epsilon, so it's just a question of getting that information from the user = to the function call. The main question I have is how to give the user a way to specify this epsilon while maintaining backward compatibility. Right now the interface for multiroot solvers is well-defined: alloc, set, iterate, and free. The most obvious place to introduce an additional parameter would be in the "set" call, gsl_multiroot_fsolver_set(), but currently there's no facility there for another parameter. We could add another argument to the call which would contain the epsilon value. Just tacking it on would lose backward compatibility, but we could create an additional "set" call, something like gsl_multiroot_fsolver_params_set(). This call would have an additional argument, something like "fsolver_params" which would be a structure with additional parameters for the solver including the epsilon value. We would then have two "set" calls for fsolvers. Using a new structure allows for future parameters to be added if needed. Another option which leaves the current user interface intact would be to add the epsilon parameter to the gsl_multiroot_fsolver structure. In the function gsl_multiroot_fsolver_alloc() function the epsilon value would be set to the current default of GSL_SQRT_DBL_EPSILON to maintain backward compatibility. If the user wanted it to be something different, he would set the epsilon value manually with a line of code like solver->epsilon =3D 1.0e-4 at a point after the solver allocation but before the call to gsl_multiroot_fsolver_set(). This option has the advantage of maintaining t= he current user interface, but establishing a manual bypass to it doesn't seem like a good design choice. I am interested in hearing from other GSL developers and users which option they think is the most appropriate for this library. Personally I think the first option, adding a new "set" call with an additional argument, is the cleanest way to go, though it does expand the user interface. -Bill Maier