mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Swamy <mnnav...@gmail.com>
Subject Re: The New Scala API
Date Tue, 01 May 2018 21:48:45 GMT
I think this project is going to significantly improve the usability of
MXNet-Scala APIs.

I had a offline discussion with Qing about this. I agree with Yizhi that
keeping in the same namespace will make it easy for existing and new users
to quickly lookup the APIs. Along with that I have one recommendation,
first generate a trait for all the APIs and have the the instance in the
existing symbol. The usage would be something like below:

trait SymbolAPIBase {
/**
api doc
*/
def Activation()
}

object SymbolAPI extends SymbolAPIBase {
def Activation()
}

object Symbol {
 val api: SymbolBase = new SymbolAPI()
}

Now users would use it as
Symbol.api.Activation()

Creating a trait/Interface as several advantages:
1) User do not have to know which concrete class to use, can be decided
later(Dependency Injection or Configuration driven application)
2) Easier to change the implementation later without breaking the user code
-> You can insert different implementations through configuration using
frameworks such as Spring, etc., -> This is standard in most JVM driven
projects
3) Easier to Unit test -> You can create Mocks easily using Mockito
4) helps with multiple inheritance…you cannot inherit multiple classes

Let me know what do you guys think.

Thanks, Naveen

On Sun, Apr 22, 2018 at 9:09 PM, YiZhi Liu <liuyizhi@apache.org> wrote:

> I personally like the design here. Since we have seen technical
> difficulties of compatibility, I would like to ask people pay
> attention to the 'How to combine with existing APIs' section:
> https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Scala+API+Usability+Improvement#MXNetScalaAPIUsabilityImprovement-
> HowtocombinewithexistingAPIs
>
> Qing proposed three options,
>
> 1. Add a new Class/Object called "NewSymbol/NDArray" with full
> implementation.
> 2. Create a new Class and change the name space for all of the
> functions (e.g Activation -> NewActivation) and let Symbol/NDArray
> extends that.
> 3. Create a new Class and override the Same functions with different
> implementations.
>
> If we have to choose from option 1 and 2, I would like to +0.5 for
> option 2, with which users can quickly aware of the new easy-to-use
> API: they type 'Symbol.' in IDE as usual and these functions pop up.
>
> 2018-04-19 10:58 GMT-07:00 Qing Lan <lanking520@live.com>:
> > Hi All,
> >
> > I am Qing, one of the Scala API maintainer for MXNet. I would like to
> propose a new design on Scala APIs, it will be really helpful for user to
> use MXNet Symbol/NDArray. This is a follow-up from Naveen’s proposal.
> >
> > Background:
> > The current design on Scala would take arguments as key-value pair and
> didn’t provide the type information for different arguments. There are
> document missing for different functions which makes it even hard to use.
> >
> > Our approach:
> > We will provide a better designed Scala API for user to use with full
> documentation and arguments definition. All arguments will be specifically
> targeted to different functions. Please see one example that we show in the
> Wiki<https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Scala+API+Usability+Improvement> and leave any thoughts you may
> have. This wiki includes examples, targets and scenarios we have so far.
> >
> > Thanks,
> > Qing
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message