
Grenade: Deep Learning in Haskell - vonnik
https://github.com/HuwCampbell/grenade
======
sndean
In the discussion of HLearn [0] the author said this [1]:

"This is a bit awkward for me as I've paused the development of HLearn and
emphatically do not recommend anyone use it. The main problem is that Haskell
(which I otherwise love) has poor support for numerical computing."

Can anyone expand on this comment, and does that also apply to Grenade?

[0]
[https://news.ycombinator.com/item?id=14402378](https://news.ycombinator.com/item?id=14402378)

[1]
[https://news.ycombinator.com/item?id=14409595](https://news.ycombinator.com/item?id=14409595)

~~~
nanolith
Haskell has a mature FFI. If there are any computational hurdles, it is
possible to drop down to C/C++ to manage these. A good library can easily
encapsulate this.

Of course, there is the point where such a library becomes a thin wrapper
around an efficient numerical library written in C, but there are other
advantages to Haskell that might make such a wrapper still worth the trade: an
amazing type system, libraries that take advantage of this type system, and a
compiler that generates fairly efficient code. If, in exchange for that, I
have to marshal numerical data into and out of Haskell's FFI, I consider it a
fair trade.

~~~
ferdterguson
I've used Haskell a little. I understand the benefits of the type system from
the perspective of something like a web app or libraries with abstractions.
However, as someone who spends their days working on numerical code in Cython
for research software, how would I actually leverage the type system in my
numerical code? Would I ever leverage the power of the type system and define
my own types?

It also seems like a terrible idea to use recursion to solve multidimensional
array problems typically associated with loops and the indexing of those
arrays.

~~~
axman6
Recursion is only a bad idea in languages with poor support for recursion,
it's not difficult to write efficient Haskell code which produces good
assembly with fairly obvious recursive algorithms. Optimisations like stream
fusion and libraries like foldl also contribute to really good code generation
(not guaranteed and also not generally applicable optimisations, but certainly
helpful)

~~~
mr_overalls
Does Haskell provide tail-call optimization or similar optimization to take
away the stack-space costs of recursive function calls?

~~~
Terribledactyl
GHC can, if you want it to. It's hard to answer in a general way because of
the laziness, and you can always force evaluation. But then you rob GHC of
potentially better optimizations, like never executing it in the first place.

This SO does a good job of explaining the trade offs.
[https://stackoverflow.com/questions/13042353/does-haskell-
ha...](https://stackoverflow.com/questions/13042353/does-haskell-have-tail-
recursive-optimization)

------
cs702
Looks really neat: composable, "smartly typed," easy-to-specify neural nets.

The main issue that keeps me from giving this a try is the lack of GPU support
out-of-the-box, necessary for tackling problems of more interesting size :-(

------
lpage
Thought of the day: bridge Grenade with like CλaSH [1] and realize network
topologies directly on an FPGA.

[1] [http://www.clash-lang.org/](http://www.clash-lang.org/)

~~~
eli_gottlieb
Ah, the wondrous things we could all do with Haskell, if only we neither had
nor needed day-jobs.

~~~
lr4444lr
I can't upvote this enough.

------
mark_l_watson
Great project! It was easy to build and run the tests, and, the examples are
very readable. Good job. I can't wait to have time to really kick the tires.

------
dannycastonguay
Thanks Huw! I'm sure many of us have been itching to do it for some time.

