[CANCELLED][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2
Dear community - I'm cancelling the vote due to -1 feedback from Luciano due to RAT failures. For details see https://lists.apache.org/thread.html/51e9ab05edae2089c74a253000a92d5aa5c6406f54e5bd0a0b3c3879@%3Cgeneral.incubator.apache.org%3E The MXNet community will discuss next steps. Regards, Steffen
Re: First class support for MxNet?
Those are compelling points! There's also another more recent follow-up from the Julia team: https://julialang.org/blog/2018/12/ml-language-compiler . It seems that Julia will likely have it's place in ML regardless of how other tools progress; the latest offerings from Julia/Flux are really compelling. Wondering where that leaves MxNet... Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Sat, Feb 9, 2019 at 11:02 PM Iblis Lin wrote: > (well, I'm a Julia programmer, my opinion might be quite bias. :p) > > No. I think Python is still dominating at this moment. > I agree the Julia blog post about ML and PL > (it also mentioned in that Swift artical): >https://julialang.org/blog/2017/12/ml > >(Chinese version) >https://julialang.org/blog/2017/12/ml >https://julialang.org/blog/2017/12/ml_tw > > TL;DR from my view: > (Quote from the blog) > "Any sufficiently complicated machine learning system contains an ad-hoc, > informally-specified, bug-ridden, slow implementation of half of a > programming language." > > Runtime & Ecosystem > Basically, I will say that TensorFlow/MXNet/PyTorch are different > standalone > programming languages for specific domain -- numerical computation. > They use Python as their interfaces to build models. > Where do the models get computed? In their own runtime. > This runtime shares nothing with CPython's runtime. > User puts "+-*/" symbols and placeholders in Python, > but nothing is computed by CPython. > > So...what's the problem about having own runtime? > In case of TF/MXNet/PyTorch, they splits and throws away the original > ecosystem. > For example, MXNet have its own array type 'NDArray'. > This type only run on our own runtime (libmxnet). > You have to abandon the great works done by scikit-learn from the > ecosystem of Scipy project, which people have already devoted tons of > efforts to. > You need to re-write a porting for NDArray if you want something like > Gaussion Process. > And this builds a wall between libmxnet and numpy runtime. > > I feel so sorry about another example: > > https://mxnet.incubator.apache.org/versions/master/api/python/ndarray/linalg.html > This API was added about 1 year ago (or half year ago?). > It made me anxious. > Tons of numerical systems have more robust and versatile linear algebra > functions. > But some of MXNet developers have to spend their valuable time on > implement linalg > stuffs again. > > About Julia's ecosystem > (Alought selling Julia is not the point.) > Let's talk about what Julia comminuty have done on integrating ecosystem. > There is a package named Flux.jl[1]. > It fully untilized Julia's native Array type and runtime. > For a CPU run, the code is written in pure Julia, and the performance is > quite > competitve[2] for the case of all the code written in high-level > language. > So that I can do some small experiemnts on my FreeBSD desktop > without compiling any C/Cpp extension. > For GPU run, there is a crazy package CUDANative.jl[3] to let user write > kernel code > in pure Julia. It leverages LLVM's PTX backend. > This package is baked by JuliaGPU[4] comminuty. > About AD stuffs, it's supported by another group of poeple from > JuliaDiff [5], > who is doing reseaches on ODE/PDE. > Flux integrates them all and become a part of ecosystem as well. > If user want to use some exotic statistic distributions, just plug the > another > package from JuliaStats[6]. > > > Any plans to take an approach similar to this for the MxNet library? > > TBH, I'm selfish. My answer is Julia. I only care about Julia stuffs. > I'm trying to make more re-use of interfaces from Julia's stdlib and > runtime. > It' challange. I hope the MXNet Julia package is more than a binding and > connecting with the ecosystem. > > So... you might ask that why I'm here and work on MXNet? > I want to increase the entroy of DL tools in Julia. > I think freedom is the symbol in the world of open source, > user should always have anothr choice on softwares. > I personally dislike the state of TF -- being a huge, closed ecosystem. > Many poeple is porting stuffs into TF's system and nothing fed back > ( the backprop got truncated :p ). > I think Julia can find a balance point between MXNet's and original > ecosystem. > > > [1] https://fluxml.ai/ > [2] > https://github.com/avik-pal/DeepLearningBenchmarks#cpu-used-intelr-xeonr-silver-4114-cpu--220ghz > [3] https://github.com/JuliaGPU/CUDAnative.jl > [4] https://github.com/JuliaGPU > [5] https://github.com/JuliaDiff > [6] https://github.com/JuliaStats > > Iblis Lin > 林峻頤 > > On 2/10/19 4:08 AM, Zach Boldyga wrote: > > Any plans to take an approach similar to this for the MxNet library? > > > > > https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md > > > > -Zach > > >
Re: Gluon fit API- Design proposal
Wanted to chime in as well. I have reviewed the design shared in the mail offline with Ankit, Lai and Naveen (we work in the same team in Amazon). I think it does a good job at simplifying many low-complexity training use cases, which can make MXNet/Gluon even more friendly to so-called "deep learning beginners" - so +1 on the proposal! Hagay On Fri, Feb 8, 2019 at 10:30 AM Naveen Swamy wrote: > Hi Alfredo, > Thanks for your comments, I really like all your suggestions. Here are my > answers let me know if it makes sense or have comments. > > 1) The fit API is targeting novice users covering about 80% of the use > cases listed in the document. For advanced users, > and complex models, we (Naveen, Ankit and Lai) felt its best use the > existing mechanisms due to the imperative nature and the more control it > can give, So we did not duplicate the save/load functionality in the Hybrid > block. > We’ll consider and extend the functionality to Estimator. > I have had trouble using pickle package which is commonly used for > serialization and deserialization, if you have any other suggestions from > your experience please let us know. > > 2) +1, we’ll add this to our backlog and add it in our next iteration. > > 3) Can you expand a little more on this, how it helps in a production > environment (which this API was not target for) ?. > I’ll check the TF Estimator to understand further. > > Thanks, Naveen > > > On Thu, Feb 7, 2019 at 2:32 PM Alfredo Luque > wrote: > > > This is great and something we should all be able to benefit from. > > > > There are just three pieces I’d like to advocate for that I feel are > > shortcomings of some competing APIs on other frameworks (eg; TF > Estimators) > > and I would love to see in this proposal: > > > > 1) Make serialization/deserialization of these classifiers/regressors > easy > > or at least ensure the internal members of the wrapper are easy to > > save/load. We’ve hacked around this by only allowing hybrid blocks which > > have easy save/load functionality, but having a simple > > “save_model”/“load_model” function as a 1st class citizen of these > proposed > > APIs will lead to a vastly improved user experience down the road. > > > > 2) Allowing the fit/predict/predict_proba functions to take in both data > > loaders and simple numpy arrays and pandas dataframes is a simple change > > but a huge usability improvement. Power users and library authors will > > appreciate being able to use custom data loaders but a large portion of > end > > users want to just pass an ndarray or data frame and get some results > > quickly. > > > > 3) Allow lazy construction of the model. This is something I feel TF > > Estimators do well: by allowing the user to pass a function that > constructs > > the net (i.e a model_fn that returns the net) rather than the net itself > it > > allows for more control at runtime and usage of these APIs in a > production > > environment. > > > > Would love your thoughts on these three changes/additions. > > > > —Alfredo Luque > > Software Engineer > > Machine Learning Infrastructure > > Airbnb > > San Francisco, CA > > > > On February 7, 2019 at 1:51:17 PM, Ankit Khedia (khedia.an...@gmail.com) > > wrote: > > > > Hello dev@, > > > > Training a model in Gluon requires users to write the training loop, this > > is useful because of its imperative nature, however repeating the same > code > > across multiple models can become tedious and repetitive with boilerplate > > code. The training loop can also be overwhelming to some users new to > deep > > learning. Users have asked in [1] for a simple Fit API, similar to APIs > > available in SKLearn and Keras as a way to simplify model training and > > reduce boilerplate code and complexity. > > > > So, I along with other contributor Naveen and Lai came up with a fit API > > proposal in [2] that covers 80% of the use-cases for beginners, the fit > API > > does not replace the gluon training loops. The API proposal is inspired > by > > the Keras fit API. I have discussed and got feedback from a few MXNet > > contributors (Sheng, Mu, Aston, Zhi) close by and I am writing to ask for > > the community’s feedback on the API proposal. > > > > > > > > [1] > > > https://discuss.mxnet.io/t/wrapping-gluon-into-scikit-learn-like-api/2112 > > [2] > > > > > https://cwiki.apache.org/confluence/display/MXNET/Gluon+Fit+API+-+Tech+Design > > > > > > Thanks, > > Ankit > > > > > > — > > Alfredo Luque > > Software Engineer > > Machine Learning Infrastructure > > Airbnb > > San Francisco, CA > > >
