+1 to consistent interfaces for machine learning algorithms. On Wed, Nov 11, 2015 at 9:29 AM, Randy Zwitch <randy.zwi...@fuqua.duke.edu> wrote:
> Sure. I'm not against anyone doing anything, just that it seems like Julia > suffers from an "expert/edge case" problem right now. For me, it'd be > awesome if there was just a scikit-learn (Python) or caret (R) type > mega-interface that ties together the packages that are already coded > together. From my cursory reading, it seems like TensorFlow is more like a > low-level toolkit for expressing/solving equations, where I see Julia > lacking an easy method to evaluate 3-5 different algorithms on the same > dataset quickly. > > A tweet I just saw sums it up pretty succinctly: "TensorFlow already has > more stars than scikit-learn, and probably more stars than people actually > doing deep learning" > > > > On Tuesday, November 10, 2015 at 11:28:32 PM UTC-5, Alireza Nejati wrote: >> >> Randy: To answer your question, I'd reckon that the two major gaps in >> julia that TensorFlow could fill are: >> >> 1. Lack of automatic differentiation on arbitrary graph structures. >> 2. Lack of ability to map computations across cpus and clusters. >> >> Funny enough, I was thinking about (1) for the past few weeks and I think >> I have an idea about how to accomplish it using existing JuliaDiff >> libraries. About (2), I have no idea, and that's probably going to be the >> most important aspect of TensorFlow moving forward (and also probably the >> hardest to implement). So for the time being, I think it's definitely >> worthwhile to just have an interface to TensorFlow. There are a few ways >> this could be done. Some ways that I can think of: >> >> 1. Just tell people to use PyCall directly. Not an elegant solution. >> 2. A more julia-integrated interface *a la* SymPy. >> 3. Using TensorFlow as the 'backend' of a novel julia-based machine >> learning library. In this scenario, everything would be in julia, and >> TensorFlow would only be used to map computations to hardware. >> >> I think 3 is the most attractive option, but also probably the hardest to >> do. >> >
