-- 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_different... Regards, apfelmus