Please note that this is a really a TOY nn project, actually a direct translation of gigasquid's nn hello-world. It is ridiculous to compare it with a library that delegates nn work to cuDNN. And it is a really old version of affe, that ddosic has improved in the meantime, but have not yet released.
What could be fair, for example, is to compare affe with another toy library built with core.matrix, or to compare a cuDNN bindings built with help from neanderthal's CUDA engine (not yet available) with Cortex, or to compare Cortex with something that delegates to one of experimental OpenCL-based "real" nn libraries... On Thursday, October 20, 2016 at 3:13:40 PM UTC+2, Boris V. Schmid wrote: > > Small addition to this post: > > There is a tiny library (toy project) of ddosic, who build a neural > network with neanderthal. It might be interesting as a benchmark of what > speed neanderthal can reach (although it might not currently be a good > reflection of neanderthal), versus larger packages with more overhead. > > https://github.com/ddosic/affe > > On Monday, May 30, 2016 at 8:34:41 PM UTC+2, kovasb wrote: >> >> Anyone seriously working on deep learning with Clojure? >> >> I'm working with Torch at the day job, and have done work integrating >> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what >> needs to be done. A bit too much to bite off on my own in my spare time. >> >> So is anyone out there familiar enough with these tools to have a >> sensible conversation of what could be done in Clojure? >> >> The main question on my mind is: what level of abstraction would be >> useful? >> >> All the existing tools have several layers of abstraction. In Tensorflow, >> at the bottom theres the DAG of operations, and above that a high-level >> library of python constructs to build the DAG (and now of course libraries >> going higher still). In Torch, its more complicated: there's the excellent >> tensor library at the bottom; the NN modules that are widely used; and >> various non-orthogonal libraries and modules stack on top of those. >> >> One could try to integrate at the bottom layer, and then re-invent the >> layers above that in Clojure. Or one could try to integrate at the higher >> layers, which is more complicated, but gives more leverage from the >> existing ecosystem. >> >> Any thoughts? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
