aaronmarkham commented on a change in pull request #13657: update with release 
notes for 1.4.0 release
URL: https://github.com/apache/incubator-mxnet/pull/13657#discussion_r242241456
 
 

 ##########
 File path: NEWS.md
 ##########
 @@ -1,6 +1,565 @@
 MXNet Change Log
 ================
 
+## 1.4.0
+### New Features
+#### Java Inference API
+
+Model inference is run and managed by software engineers in a production 
eco-system which is built with tools and frameworks that use Java/Scala as a 
primary language. Inference on a trained model has two different use-cases:
+
+  1. Real time or Online Inference - tasks that require immediate feedback, 
such as fraud detection
+  2. Batch or Offline Inference - tasks that don't require immediate feedback, 
these are use-cases where you have massive amounts of data and want to run 
Inference or pre-compute inference results 
+Batch Inference is performed on big data platforms such as Spark using Scala 
or Java while Real time Inference is typically performed and deployed on 
popular web frameworks such as Tomcat, Netty, Jetty, etc. which use Java.  With 
this project, we want to build a new set of APIs which are Java friendly, 
compatible with Java 7+, are easy to use for inference, and lowers the entry 
barrier of consuming MXNet for production use-cases. More details can be found 
at the [Java Inference API 
document](https://cwiki.apache.org/confluence/display/MXNET/MXNet+Java+Inference+API).
+
+#### Julia API 
+
+MXNet.jl is the Julia package of Apache MXNet. MXNet.jl brings flexible and 
efficient GPU computing and state-of-art deep learning to Julia. Some highlight 
of features include:
+
+  * Efficient tensor/matrix computation across multiple devices, including 
multiple CPUs, GPUs and distributed server nodes.
+  * Flexible symbolic manipulation to composite and construct state-of-the-art 
deep learning models.
+
+#### Control Flow Operators
+
+Today we observe more and more dynamic neural network models, especially in 
the fields of natural language processing and graph analysis. The dynamics in 
these models come from multiple sources, including:
+
+  * Models are expressed with control flow, such as conditions and loops;
+  * NDArrays in a model may have dynamic shapes, meaning the NDArrays of a 
model or some of the NDArrays have different shapes for different batches;
+  * Models may want to use more dynamic data structures, such as lists or 
dictionaries.
+It's natural to express the dynamic models in frameworks with the imperative 
programming interface (e.g., Gluon, Pytorch, TensorFlow Eager). In this 
interface, users can simply use Python control flows, or NDArrays with any 
shape at any moment, or use Python lists and dictionaries to store data as they 
want. The problem of this approach is that it highly depends on the front-end 
programming languages (mainly Python). A model implemented in one language can 
only run in the same language. A common use case is that machine learning 
scientists want to develop their models in Python but engineers who deploy the 
models usually have to use a different language (e.g., Java and C). Gluon tries 
to close the gap between the model development and deployment. Machine learning 
scientists design and implement their models in Python with the imperative 
interface and Gluon turns the implementations into symbolic implementations by 
simply invoking hybridize() for model exporting. 
 
 Review comment:
   ```suggestion
   It's natural to express dynamic models in frameworks with an imperative 
programming interface (e.g., Gluon, Pytorch, TensorFlow Eager). In this kind of 
interface, developers can use Python control flows, or NDArrays with any shape 
at any moment, or use Python lists and dictionaries to store data as they want. 
The problem of this approach is that it highly dependent on the originating 
front-end programming language (mainly Python). A model implemented in one 
language can only run in the same language. 
   
   A common use case is that machine learning scientists want to develop their 
models in Python, whereas engineers who deploy the models usually have to use a 
different "production" language (e.g., Java or C). Gluon tries to close the gap 
between the model development and production deployment. Machine learning 
scientists design and implement their models in Python with the imperative 
interface, and then Gluon converts the implementations from imperative to 
symbolic by invoking `hybridize()` for model exporting. 
   ```

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to