David Roundy wrote:
It seems like GSLHaskell is an awfully big stick, when all you need are scalar multiply and vector addition. Of course, we don't know what functions he wants to minimize, but in the absence of any need for GSL functions, I don't see a good reason for it.
The function is just a linear combination of sines and cosines. No need for GSL for that.
I see that GSLHaskell has a binding to a conjugate gradients minimizer, but it's not useful for any hard problems (it stores the trajectory, which defeats the purpose of using conjugate gradients), and can only be very, very slow.
I had been throwing the trajectory away without any more thought, but I suppose it would slow things down quite a bit.
>From the API alone it cannot be efficient. Code that is written by people who obviously either don't know or don't care about efficiency is just not in general a good idea. I don't know what you use GSLHaskell for in your work, but I hope you don't use it for conjugate gradients, or only use it on easy problems.
I agree, given the API it seems like it could be very nice for visualizing how CG works, but it does seem to rule out high performance.
-- David Roundy Department of Physics Oregon State University
Chad Scherrer _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
