guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I wrote fluid advection code: How to make this more elegant?


From: Arne Babenhauserheide
Subject: Re: I wrote fluid advection code: How to make this more elegant?
Date: Sun, 24 Jan 2016 16:04:40 +0100
User-agent: mu4e 0.9.15; emacs 24.5.1

Panicz Maciej Godek writes:
> although I cannot be of immediate help with the topic, because I don't know
> anything about advection, I think that the main problem with your code is
> that it is imperative. While Python's stylistics handles the imperative
> code quite nicely, it looks rather strange in Scheme.
>
> From my experience, the proper Scheme solution should resemble the
> mathematical formulation of a problem (except that it should be more
> descriptive), rather than a list of steps for solving it.

That’s a good point — I should have given the mathematical formulation
along with the code. The advection equation this implements is:

(φ_j,n+1 - φ_j,n)/Δt
  + c(φ_j+1,n - φ_j-1,n)/2Δx
  - (c² Δt/Δx) * (φ_j+1,n - 2φ_j,n + φ_j-1,n) / 2Δx
  = 0

[sadly this isn’t easy to read, either, but it’s the math which needs 
implementation]

> Also, it should be more readable to use pattern matching instead of list
> indexing, so most likely your expression
>
> (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))
>
> should look like this
>
> (map (lambda (prev this next)
>           (- this
>              (* c1 (- next prev))
>              (* (- c2) (+ next (* -2 this) prev))))
>        `(0 ,@(drop psir 1))
>        psir
>        `(,@(drop-right psir 1) 0))
>
> While this may also look slightly difficult to read (and write),

I think it already helps a lot, that this is shorter (prev this next
clearly wins against (+/- i 1)).

> this isn't solely because of the expression's structure, but because
> the factors of the expression have no name, and therefore the source
> code doesn't explain their role (this is the problem of the Python
> code either, but Python doesn't prompt to fix that)

that part is already in the math, but using variables with better names
sounds like an improvement.

Thank you!

> PS I think that this subject fits better to guile-user

You’re right — sorry. I’m still spoiled by projects where exactly one
mailing list is active…

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]