On Friday, 7 October 2016 08:25:31 UTC+8, kovasb wrote: > > On Thu, Oct 6, 2016 at 4:46 PM, Dragan Djuric <drag...@gmail.com > <javascript:>> wrote: > > >> s more harm than good. I prefer to give users one Ford model T, than let >> them choose between 20 different horse carriages. And, if they can even >> choose the color, provided that their choice is black :) >> > > Thanks the for the comments, which I largely agree with. > > I understand your design philosophy and agree its a useful point in the > space to have. > > One question: > > Is it possible to feed Neanderthal's matrix representation (the underlying > bytes) into one of these other libraries, to obtain > computations Neanderthal doesn't support? > > My situation: Neanderthal covers some of the algorithms I'd like to > implement. It looks easier to get started with and understand than the > alternatives. But down the line I'll likely want to do convolution, > sigmoid, the typical Neural Network layers. Note, I don't care about > 'tensors' exactly; the bookkeeping to simulate a tensor can be automated, > but the fundamental operations cannot. So there is a question of whether to > just absorb the learning curve and shortcomings of these more general > libraries rather than to risk switching horses midstream. > > I imagine I'm not alone in this.. if there was a straightforward story for > how to interop Neanderthal when necessary with some more general library > that would be powerful. Unfortunately I'm not sufficiently expert to > evaluate which of the choices would be most pragmatic and how to pull it > off. >
I'm hoping to work with Dragan to get core.matrix integration working with Neanderthal, now that Windows support is finally arriving. This would get you a few big advantages: 1. Neanderthal could be used as a drop-in replacement for other core.matrix implementations if it fits your use case 2. You would get extra core.matrix features (additional operations, higher dimensional array operations, type conversion, broadcasting etc. essentially for free) 3. We minimise the risk of fragmentation in the Clojure numerical ecosystem :-) 4. We could use Neanderthal as a optional backend for libraries like Incanter or our new NN libraries without any major re-engineering I'm certainly willing to contribute a fully compliant core.matrix implementation for Neanderthal (will take me a couple of days as long as the Windows build works smoothly). This might not optimise all of the possible operations, but should get high performance in most of the common use cases. Hope you will all support this effort! > -- 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.
