[Haskell-cafe] suggestions about a library for numerical calculation

Tom Nielsen tanielsen at gmail.com
Tue Nov 25 15:08:00 UTC 2014


Felipe,

Here is a fairly detailed paper that describes an image processing pipeline
that was state-of-the-art a few years ago, before Deep Learning became the
new uber-buzzword:

https://hal.inria.fr/hal-00830491/PDF/journal.pdf

this is probably still competitive in performance to within a few percent.
We are using CUDA code from
https://dms.sztaki.hu/en/project/gaussian-mixture-modeling-gmm-and-fisher-vector-toolkit

Tom

On Tue, Nov 25, 2014 at 12:07 PM, Dominic Steinitz <dominic at steinitz.org>
wrote:

> There’s at least two answers to this. 1) Most numerical methods do not
> have a native Haskell implementation (on Hackage) probably even RK4 so the
> world is your oyster 2) Most numerical methods have a highly optimised
> implementation that worries about overflow and underflow etc probably
> written in Fortran but maybe in C so why re-invent the wheel but just
> provide bindings to them.
>
> My answer is that I would like to have my cake and eat it and I think the
> new Numeric.LinearAlgebra.Static module starts to do this. I get type
> safety at compile time and I get speed. Frank tells me he can get pretty
> close to C speed using unboxed vectors. Maybe we can go even faster using
> unsafe operations but keeping static guarantees by exploiting the type
> system in the same way that HMatrix does (type level literals).
>
> Here’s what I would do if I had time. Look at Julia, pick an interesting
> library / application, use Vector and Repa to implement, compare speeds
> while using type level programming to preserve safety. I’d like Haskell to
> be faster and safer.
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 24 Nov 2014, at 12:05, Tom Nielsen <tanielsen at gmail.com> wrote:
>
> I'd say we're lacking in the optimization and classification department.
> While there are libraries for this, they are mostly bindings to C libraries
> which makes it more difficult to get information out of the algorithm. We
> have implemented BFGS and Nelder-mead here:
> https://github.com/glutamate/probably-baysig/tree/master/src/Math/Probably
> but that isn't officially open sourced (and lacking L-BFGS).
>
> We're also a lot of image processing now, and native Haskell
> implementations of SIFT and Gaussian mixture model fitting would be
> extremely useful.
>
> Tom
>
>
>
> On Thu, Nov 20, 2014 at 5:44 PM, felipe zapata <tifonzafel at gmail.com>
> wrote:
>
>> Hi all,
>>  I want to develop some tools on top of Vector and Repa, and I've
>> wondered what tools   could be useful that are not already on hmatrix.
>>
>> Any suggestions would be appreciated,
>>
>> Felipe Z.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141125/fa5f1984/attachment.html>


More information about the Haskell-Cafe mailing list