[Haskell-cafe] Re: small boys performance

[apfelmus at quantentunnel.de]

-- redirected from haskell.general

Andrzej Jaworski wrote:
> As I regretfully pointed out earlier in [Fwd: Re: Computer Language
> Shootout]
> large search and simulations are not for Haskell. This is equally true with
> GHC 6.5 http://eric_rollins.home.mindspring.com/haskellAnt.html.

Indeed, directly translated ML code is not for Haskell. Or did you
really expect Array (Int,Int) Double, ubiquitous tail recursion and
accumulating nodes at the end of a list (nextPath = path ++ [nextCity])
to give you simulation wonders?

Btw, there are a lot of opportunities for abstraction, separation of
concerns and reuse in the code. There are much to many to list them all,
but here are few:

- Most importantly, iterations are best separated into generation and
selection:

   bestPath = last . iterate (evolve)

There is really no need (and it hurts performance, you know) to have
this parameter hell.

- By grouping paths with their total scores like in

   data Path = Path { nodes :: [Node], score :: Int }

you can define a very convenient

   best :: Path -> Path -> Path

that chooses the one with the greater score. More general, you can define

   maxBy :: (a -> Double) -> a -> a -> a
   maxBy f x y
       if f x >= f y then x else y

- Considering a minor stylistic point,

   incrs = [ (fromIntegral boost) | n <- pairs ]
   pairsWithInc = zip pairs incrs

is best known as

   pairsWithInc = zip pairs $ repeat (fromIntegral boost)

- Abstraction from the concrete graph implementation enables switching
from Array (Int,Int) Double to a sparse representation if demanded,
namely a nested IntMap (IntMap Double).

- etc.


> calculating a tensors with symbolic indices (without components)
> so that one could have components calculated for specific cases on the end
> of general calculation.

http://www.nt.ntnu.no/users/haugwarb/Programming/haskell_automatic_differentiation_III.pdf


Regards,
apfelmus