From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: I wrote fluid advection code: How to make this more elegant? Date: Mon, 25 Jan 2016 01:21:17 +0800 Organization: HFG Message-ID: <1453656077.3214.53.camel@Renee-desktop.suse> References: <87io2kpqdq.fsf@web.de> <877fj0lb64.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453656099 1182 80.91.229.3 (24 Jan 2016 17:21:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 17:21:39 +0000 (UTC) Cc: Arne Babenhauserheide , guile-devel@gnu.org To: Taylan Ulrich =?UTF-8?Q?Bay=C4=B1rl=C4=B1/Kammer?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 24 18:21:39 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aNOM6-0002sj-PK for guile-devel@m.gmane.org; Sun, 24 Jan 2016 18:21:38 +0100 Original-Received: from localhost ([::1]:32946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOM6-0007c5-7t for guile-devel@m.gmane.org; Sun, 24 Jan 2016 12:21:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOLz-0007bz-Ra for guile-devel@gnu.org; Sun, 24 Jan 2016 12:21:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNOLu-0002JM-R9 for guile-devel@gnu.org; Sun, 24 Jan 2016 12:21:31 -0500 Original-Received: from mail-pf0-x230.google.com ([2607:f8b0:400e:c00::230]:33233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOLu-0002JH-J2 for guile-devel@gnu.org; Sun, 24 Jan 2016 12:21:26 -0500 Original-Received: by mail-pf0-x230.google.com with SMTP id e65so69490393pfe.0 for ; Sun, 24 Jan 2016 09:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:content-type:mime-version:content-transfer-encoding; bh=sIO1FYs3GXcJTpSbxNzTIYzdyWziF1WYzKs9aeeEcqs=; b=sal3/tKM5nQJrIL/y9+bMdC7zTweK9appaSxSUSrnjfI44l/h6LcYBG37Cq9O8zlKO UN0Wjrl3W46T3D39lquQPTM9YjBvQxlznKwZ0m5Z0zvh3UITvs7cEhybZf0zsvc0ytYm hn99q2VxVWRQcnn+Tan94QlZW+Qr8Vz/5rNdAxaoYdK2zcLJAxeVZjjkHjzO3VJZQIqd mKgsZR4tbqSxCRBdB1c79oha/O36l2c9B0gKQ5z/Nv/wX6kHMTjsE3x6T+v3gMqYr8N3 TocBJc/pBOpffsNfkfKJDsj5cQFBrvSs7h6LrlZBgqN/HmkefP401mFHlK18VdyazRy7 OAVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:content-type:mime-version :content-transfer-encoding; bh=sIO1FYs3GXcJTpSbxNzTIYzdyWziF1WYzKs9aeeEcqs=; b=ELRc3OsPqo0T/Yf9DJ/MWVLKSi60ZE3JEpoRcenfd4eJ7wYSaExKelYbZj7ndbOmrk ijAoKU49MY4VSn7KFYiaoPLHvWqGPBIGA4RSO3BVKd16griSIfAZ9zcKG0w5lUypAnSs Ga57Jml8Lni1pdOVt+vlah4kIP6uOrgtLXJAPXouZArBWzF4NwYv6BO+1d/r4tVv4YF6 e6Qj6cM3eVU615y1QXdGHc13RVFmih4crQ4uNYHldL4dIaj5hFrPkl4X9M9aaefsSJZA hlQDOjs1anfOAcv5YPe+40prPZ4XR6LOjKrR8m0I9f6F6XqSvjjAKsqqzUZCyL1wdZKR 0/uQ== X-Gm-Message-State: AG10YOSIS9fHcQyofCSQO97FyeMXR6Q0DNsapmixfMHWETgZvJwdQIoYNSP0RZaS2q0wlw== X-Received: by 10.98.68.199 with SMTP id m68mr19921286pfi.6.1453656085609; Sun, 24 Jan 2016 09:21:25 -0800 (PST) Original-Received: from [127.0.0.1] (li88-185.members.linode.com. [74.207.246.185]) by smtp.gmail.com with ESMTPSA id h66sm22844391pfj.52.2016.01.24.09.21.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 09:21:24 -0800 (PST) In-Reply-To: <877fj0lb64.fsf@T420.taylan> X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c00::230 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:18132 Archived-At: The math formula may take advantage of sweet expression which is contained in the current Guile reader, IIRC. One may give it a try? On Sat, 2016-01-23 at 13:42 +0100, Taylan Ulrich Bayırlı/Kammer wrote: > Arne Babenhauserheide writes: > > > Hi, > > > > I just recreated a fluid advection exercise in Guile Scheme and I’m not > > quite happy with its readability. Can you help me improve it? > > > > My main gripe is that the math does not look instantly accessible. > > > > The original version was in Python: > > > > psi[i] - c1*(psi[i+1] - psi[i-1]) + c2*(psi[i+1] - 2.0*psi[i] + psi[i-1]) > > > > My port to Scheme looks like this: > > > > (let ((newvalue (+ (- (psir i) > > (* c1 (- (psir (+ i 1)) (psir (- i 1))))) > > (* c2 (+ (- (psir (+ i 1)) (* 2 (psir i))) > > (psir (- i 1))))))) > > (array-set! psinew newvalue i)) > > Guile supports SRFI-105, so that could be: > > {{psi[i] - {c1 * {psi[{i + 1}] - psi[{i - 1}]}}} + {c2 * {{psi[{i + 1}] - {2 * psi[i]}} + psi[{i - 1}]}}} > > which is less readable than the Python version because there's no > first-hand support for operator precedence so we {} group all binary > operations, plus we need to use {} within [], plus we must separate > operators with whitespace, but maybe it's acceptable. > > You can put "#!curly-infix" at the start of your Scheme file to enable > SRFI-105 syntax. > > Note that all those 'psi[x]' expressions will expand to > > ($bracket-apply$ psi x) > > and you can implement a macro of that name to turn that into whatever is > suitable at compile-time. (If performance is not an issue, SRFI-123 > provides a run-time polymorphic procedure for $bracket-access$.) > > With a smart definition of $bracket-apply$, you could also cut down > those psi[{i + 1}] to psi[i + 1]. The latter will expand to > > ($bracket-apply$ psi i + 1) > > which could be accommodated for in a special-purpose definition of > $bracket-apply$ such as: > > (syntax-rules () > ((_ obj index) > (obj index)) > ((_ obj x operator y) > (obj (operator x y)))) > > That would *not* support e.g. psi[i + j - 1], which would instead need > to be written e.g. psi[{i + j} - 1], i.e. we only save one pair of {}, > but maybe that's good enough. > > By the way, e.g. {x - y + z} will turn into ($nfx$ x - y + z), and maybe > there's a definition for $nfx$ out in the wild (or you can create one) > that does operator precedence. (That could then also be used in > $bracket-apply$.) So optimally, the whole thing could become: > > {psi[i] - c1 * {psi[i + 1] - psi[i - 1]} + c2 * {psi[i + 1] - 2 * psi[i] + psi[i - 1]}} > > Taylan >