-- 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe