[Haskell-cafe] Re: small boys performance

[apfelmus]

-- 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

Re: [Haskell-cafe] Re: small boys performance

[Steve Downey]

Many years ago, I got a B- in abstract algebra, and an A+  in
differential geometry.

Now I know why I worry about the blue glow of an unplanned criticality
excursion occuring in my brain.

On 3/14/07, Dan Piponi [EMAIL PROTECTED] wrote:

On 3/14/07, Andrzej Jaworski [EMAIL PROTECTED] wrote:
 I am glad you are interested Dan.
 ...
 I do not intend to bore anybody with differential geometry but as I was
 pushed that far let me add that if Haskell was made to handle Riemannian
 geometry it could be useful in next generation machine learning research
 where logic, probability and geometry meet.

I believe that you can probably handle (pseudo-)Riemannian geometry in
the framework sketched here:
http://sigfpe.blogspot.com/2006/09/practical-synthetic-differential.html

That only goes as far as playing with vector fields and Lie
derivatives but I think that forms and tensors should fit just fine
into that framework.

There's a simple way to use types to represent tensor products, and
that's sketched here:
http://sigfpe.blogspot.com/2006/08/geometric-algebra-for-free_30.html
(Forget that that's about geometric algebra, the thing I'm interested
in is the tensor products.)

So I'm guessing there's a way of combining these to give a framework
for (pseudo-)Riemannian geometry. But it'd only be a good framework
for answering certain types of questions - in particular for things
like numerical simulation. The important thing is that you'd be able
to read off accurate numerical values of quantities like curvatures
without any need for symbolic algebra.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe