(Replying on haskell-cafe)
Let me start with a disclaimer: I haven't looked at your code
extensively. That said, the feeling that I get from it is one of
listening to a non-native speaker. The things in your program are
obviously not completely inaccurate, or they wouldn't have
type-checked. And, presumably, you've already done some testing, so it
probably produces the right answers. Similarly, there are many things
in English that you _could_ say, which would be entirely grammatically
correct, but which native speakers would never say. For example, in
your code, I noticed a pattern which I've just recently learned:
<code>
do
...
tmp <- readArray scaleInfo j
writeArray scaleInfo imax tmp
</code>
Now, if you were to de-sugar the last 2 lines, it would look something
like this:
<code>
readArray scaleInfo j >>= \tmp -> writeArray scaleInfo imax tmp
</code>
...but as soon as you see that lambda expression, you should
(hopefully) say "oh, that can be written more easily:
<code>
readArray scaleInfo j >>= writeArray scaleInfo imax
</code>
Of course, a native speaker will probably not even think about the
intermediate lambda expression, but the point is, this is an idiom.
And, really, this is a very tiny example. Your entire program is
written in a very imperative style. "Do this, then do that, then do
the other thing." And this is to be expected. After all, you said that
you were directly porting the algorithm from an imperative language.
However, if you're going to do this idiomatically, you really need to
think very differently.
I suggest reading and pondering this well-known blog entry for more
ideas about the differences between the approaches of functional and
imperative programming: http://blogs.nubgames.com/code/?p=22
Sorry, I don't have more specific suggestions, but I suspect this is
what most people thought when they read your code: it's hard to make
specific suggestions, when you're really approaching the problem in a
non-idiomatic way.
On 9/16/07, Xiao-Yong Jin
Dear Haskellers,
My thanks to people on the irc channel, especially `int-e'. With their help, I managed to write a linear equation solver using STUArrays.
It is basically a direct rewrite of a C version, which adopts Crout's LU decomposition method with implicit pivoting, in chapter 2.3 of the book Numerical Recipes.
I must admit that the code is in a really bad style, somewhat ugly, because of the limit of my Haskell knowledge. The code is attached in this email for your amusement. I would be really thankful if you can give me any kind of comments, idea, improvement, criticism, because I sincerely want to make the code better.
Best regards, Xiao-Yong -- c/* __o/* <\ * (__ */\ <
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell