From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6789 invoked by alias); 11 Jan 2014 01:58:34 -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 6779 invoked by uid 89); 11 Jan 2014 01:58:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-qe0-f51.google.com Received: from mail-qe0-f51.google.com (HELO mail-qe0-f51.google.com) (209.85.128.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 11 Jan 2014 01:58:32 +0000 Received: by mail-qe0-f51.google.com with SMTP id 1so5421430qee.10 for ; Fri, 10 Jan 2014 17:58:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=G4uzJTN+nKa6Y+9KKWAes6aIfoWi2RrDlvUqVx9W+OQ=; b=F3rWhsh1f2sh9eyeo92nP/dWyCpBfKF4QOSSw262xYCdSujWJu0Ic9YB5iN0QQp4Xe jGiTKABhgCra5TujX7P6CGvrzG0K65ujD6XI243As0NNJzJyy8pOv+RsdezmmkmpkKhm vualn+3prWms9BIaY/eNX9LhrCSPn+DlOxxFZil46OiZt62fljiHFUUhjYI2I+IIZKBi sw4xc2a6BwfRiQ+SuJ/85Mg2ZTXTkmWdKrVmemnBzNaIu/QLB6eaEdB+rYM1jpk/RewS GAA0ojjeCAe1lzBivUUGPCqsSKEqaWcvYZgLfsmCf9fBwkBiyhUV4j9frFOh3DQ6XXin t5MQ== X-Gm-Message-State: ALoCoQlNlOKdot+NubZN9pSf82cEExx438RN+Hu/ZTBwYEWnLkAY5p2y1bBV9ciTnesdlwJhfs8A X-Received: by 10.224.55.15 with SMTP id s15mr13973467qag.42.1389405510027; Fri, 10 Jan 2014 17:58:30 -0800 (PST) Received: from [192.168.1.119] (c-174-49-133-13.hsd1.pa.comcast.net. [174.49.133.13]) by mx.google.com with ESMTPSA id w7sm14532563qaj.23.2014.01.10.17.58.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 17:58:28 -0800 (PST) Message-ID: <52D0A53E.8020802@ellipsix.net> Date: Sat, 11 Jan 2014 01:58:00 -0000 From: David Zaslavsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: interp2d discussion References: <520EB115.9070606@ellipsix.net> <52CF8F04.60505@ellipsix.net> <52D021B0.6080504@colorado.edu> <1475379.W4E7QPn8Ol@tom> In-Reply-To: <1475379.W4E7QPn8Ol@tom> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5sx624TCWtU4vODXrlaLrwIs455cvqFWG" X-SW-Source: 2014-q1/txt/msg00011.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5sx624TCWtU4vODXrlaLrwIs455cvqFWG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2403 Hi Jeremy, The algorithms used by interp2d require a rectangular grid. Doing interpolation without that grid would require an entirely different algorithm, so that would be a separate project. The algorithms can be generalized to higher-dimensional interpolation, but it becomes exponentially more complicated as the number of dimensions increases. For linear interpolation this probably wouldn't be too bad, but other interpolation schemes would be quite a pain to code in a higher number of dimensions. I believe it would be possible to make an interpolation routine that automatically generalizes to any number of dimensions (I think Mathematica does this, for example), but that would require pretty much rewriting the entire code base. :) David On 01/10/2014 07:27 PM, jeremy theler wrote: > Hi all, > > I consider the addition of these routines to GSL as a major breakthrough. > Now I have three questions about generalization: > > 1. can these 2D interpolation routines be extended to scattered (i.e. no= n- > rectangular) data? > > 2. can these 2D interpolation routines be extended to n dimensions? > > 3. both > > > Thank you for your hard work! > > -- > jeremy > > > On Friday 10 January 2014 09:37:04 Patrick Alken wrote: >>> Sure, that would be a reasonable option, but I'd like to do a bit of >>> research (i.e. ask a few more people for opinions) to see what solution >>> will be the least confusing. After all, if there is a change to be made, >>> this is the time to do it, not later after the code is incorporated into >>> GSL. I think backward compatibility will not be too much of a problem >>> because people will have to make other changes anyway to transition from >>> the interp2d_* functions to the corresponding gsl_* functions. >> I think 2 additional functions could be added to help solve this issue >> and hide the indexing >> from the user: >> >> interp2d_grid_set(double zarr[], size_t i, size_t j, double z) >> { >> /* set point (i,j) of grid 'zarr' to value 'z' */ >> } >> >> and >> >> interp2d_grid_fill(double zarr[], int (*grid_func)(double x, double y, >> void *params)) >> { >> /* fill entire grid 'zarr' using callback function 'grid_func'; this >> would be useful >> * in cases where the user has a continuous/analytic function which >> is expensive to call, but >> * they'd like to make a grid and then interpolate from it >> */ >> } --5sx624TCWtU4vODXrlaLrwIs455cvqFWG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 295 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLQpUMACgkQBoP+cm/XtnQ2DwEAjyU/HN3xMDc4W2nW6/suhEMG wgPUhrFn698BNV5aGCwA/j7cXNhRt2CdbVRtSzDGS+vyqC3y1XrU0cqXCrWU884S =vvp6 -----END PGP SIGNATURE----- --5sx624TCWtU4vODXrlaLrwIs455cvqFWG--