I know it is about trade-off. I am suggesting a trade-off , how many apis do we have that takes too many parameters ? From what I recall its around 20. Why can we not create the builder just for these APIs( which we discussed), why is it necessary to add 200 Apis ? Are you suggesting to create builder for each and every API?
I disagree with your opinion that they are not important and would like to hear from others. I am curious to see how the #2 looks like compared to #1 Andrew/Qing, can you paste the generated Apis that you have for both Scala and Java in a gist please. > On Sep 29, 2018, at 2:41 PM, YiZhi Liu <eazhi....@gmail.com> wrote: > > Naveen, software designing is all about tradeoff, every feature we > introduce causes more compiling time, more efforts to maintain, etc. > > The main difference is. > > Option #1: Java users do > NDArray.BatchNorm(data, gamma, beta, null, null, null, null, null, > null, null, null, null, null, null); > (and because every operator has an argument "out", users need to add > an extra "null" to the function call almost every time.) > > Option #2, Java users do > JavaNDArray.BatchNorm(data).setGamma(gamma).setBeta(beta).invoke(); > > I don't think any of the reasons you listed is so important as the > benefit above we got from option #2. >> On Sat, Sep 29, 2018 at 8:24 AM Naveen Swamy <mnnav...@gmail.com> wrote: >> >> Java APIs are not like Clojure - The current proposal is only to build a >> few thin wrappers for Inference. >> >> To better represent the two cases and this discussion in particular, here >> is an example API >> >> 1) def Activation (data : org.apache.mxnet.NDArray, act_type : String, out >> : Option[NDArray] = None) : org.apache.mxnet.NDArrayFuncReturn >> or >> 2) def Activation (data : org.apache.mxnet.NDArray, act_type : String, out >> : NDArray) : org.apache.mxnet.NDArrayFuncReturn >> >> The discussion is should we add(generate) 200+ APIs to make it Java >> compatible, ie., remove the Option class and the None default value which >> Java does not understand from Option 1) >> >> my suggestion was to remove the Option class and create a implicit for >> backward compatibility and use null instead of None, Andrew and I disagreed >> on this, so I suggested to raise a discussion on dev@ to get more opinions >> and one of us will disagree and commit. Thanks for raising it :) >> >> | * def Activation (data : org.apache.mxnet.NDArray, act_type : String, out >> : NDArray = null) : org.apache.mxnet.NDArrayFuncReturn | >> -- >> >> 1) It is not true that Scala users will lose *default/optional* arguments - >> if we followed the above, they will use null or None, though I do not like >> using nulls, this is a fine compromise. >> To keep backward compatibility we can create a implicit to convert >> Option.None to nulls and Option.Some-> Option.get(), so you are not going >> to break users who might have been using the APIs that were released in >> 1.3. The current incompatibility is only this w.r.t. NDArrays. >> >> 2) Now about the Scala Macros - they are not simple to read or use, When I >> and Qing started working on the #Scala Macros to improve the APIs, it took >> us a good amount of time to get a hang of it. I don't want to add >> additional code when not necessary. >> >> My suggestion and vote is to modify existing Macro(i.e., #1 from the >> original email with the necessary clarification above) and make it >> compatible with Java >> Here are my reasons >> 1) The NDArray APIs in question are not following functional style of >> programming, in fact they are just static methods defined on an NDArray >> object - so Scala users are not losing much by using null in place of None. >> You can create a implicit to maintain backward compatibility >> 2) It is adding 220+ APIs(I understand it is generated) for NDArray alone >> 3) this is adding another 100s of APIs unnecessarily, we are starting with >> NDArray but we can't stop there, we will have to do this for Symbol, >> Executor, Iterators, etc., . >> 3) I don't want to be fixing bugs and maintaining code in 2 places. >> 4) I want the cryptic code(# scala macros) to a minimum. >> 5) increased compilation time & bad developer experience - the time to >> compile has gone up quite a bit since we added the APIs last release on my >> 3 year old laptop already.. I think adding 400+ APIs unnecessarily would >> significantly increase build time and bad developer experience >> 6) I want to keep the core of the framework to be in Scala - because it >> allows you to write concise code - Yes it has a bit of learning curve, not >> everyone needs to know. I would rather invest in solidifying the Scala APIs >> and add more features in Scala(RNN, Support GluonHybridizedBlock...there is >> quite bit of work ) - do you want to rewrite everything in Scala and Java. >> 7) Also, the discussion is not creating NDArray class for Java, just >> generate certain APIs to cater for Java incompatibility. >> >> @Andrew: To your response to Qing's comments - you cannot just consider it >> as just generating NDArray's APIs and instead I suggest to take a wholistic >> view of all the various implications. >> >> @Chris: Yes, Scala has a bit of learning curve - the goal is not having >> every developer to deal with how these APIs are generated, >> the problem exists either ways with the above proposal. I might agree if we >> were to move away completely(with a thorough discussion and valid reasons) >> and instead use AspectJ or similar to write these APIs, the discussion is >> about using Scala Macros to generate 2 different types of APIs which are >> functionally not different and usability wise are very very similar, look >> at the example. >> Thanks for your input, I will deposit your 0.02$ in our JIRA bank :) >> >> @Carin: It requires more effort to use AspectJ or similar to generate APIs >> using reflection or at compile time, here we need to generate at compile >> time so Java users have the API signature on their IDEs. >> >> Thanks, Naveen >> >> P.S: I am traveling and my responses will be delayed. >> >> >>> On Fri, Sep 28, 2018 at 10:25 AM Carin Meier <carinme...@gmail.com> wrote: >>> >>> Sorry bad paste on the gist - here is the good one >>> https://gist.github.com/gigasquid/01cd48f563db4739910592dd9ac9db20 >>> >>>> On Fri, Sep 28, 2018 at 10:24 AM Carin Meier <carinme...@gmail.com> wrote: >>>> >>>> +1 on option #2 >>>> >>>> In the case of minimizing the the overhead for code maintenance, I wanted >>>> to suggest the option of investigating generating code from the Java >>>> Reflection for the Java APIs. I did a quick gist from Clojure of what >>> the >>>> generated classes look like from the current Scala Symbol.api for >>>> FullyConnected here >>>> https://gist.github.com/gigasquid/01cd48f563db4739910592 >>>> >>>> I looks like that there is always a base Java class generated will all >>> the >>>> arguments. If this is the case, then there is a possibility to generate a >>>> Java api based on this Java method automatically with just a conversion >>> for >>>> the Scala option and it might be reusable for all the packages. >>>> >>>> Not sure if it will work for this use case, but thought I would bring it >>>> up in case it's helpful. >>>> >>>> - Carin >>>> >>>> On Fri, Sep 28, 2018 at 7:05 AM Davydenko, Denis <d...@amazon.com.invalid >>>> >>>> wrote: >>>> >>>>> +1 on option #2. Having clear Java interface for NDArray, from my >>>>> perspective, would be a better experience for Java users as it won't >>>>> require them to deal with Scala code in any capacity. Overhead of extra >>>>> code for additional macros is justified, in my mind, as it will be >>>>> introduced with option #1 either way, just in a different place. >>>>> >>>>> -- >>>>> Thanks, >>>>> Denis >>>>> >>>>> On 9/27/18, 6:14 PM, "YiZhi Liu" <eazhi....@gmail.com> wrote: >>>>> >>>>> I vote for "2.) Leave the existing macro in place and add another >>>>> which generates a Java friendly version" >>>>> >>>>> @Qing @Andrew, could you give some examples, so that people can >>> better >>>>> understand how it provides "best possible experience" to Java users. >>>>> >>>>> I have no strong preference between having JavaShape & JavaContext >>> or >>>>> not. >>>>> On Thu, Sep 27, 2018 at 5:56 PM Andrew Ayres < >>>>> andrew.f.ay...@gmail.com> wrote: >>>>>> >>>>>> That's not really the conversation I'm wanting to have. I want a >>>>> discussion >>>>>> about the macros with respect to NDArray so that we can get >>>>> agreement on >>>>>> our path forward with respect to implementing the NDArray wrapper. >>>>>> >>>>>> The design that was put forth and agreed to was for a a Java >>>>> wrapper around >>>>>> the Scala API. Adding a bunch of Java friendly methods inside the >>>>> Scala >>>>>> code would create a mess for users. Maintenance would be >>>>> essentially the >>>>>> same for both because either way you're going to be updating Java >>>>> methods >>>>>> when you make Scala changes. >>>>>> >>>>>> Let's please stick with the issue in the original email. >>>>>> >>>>>> Thanks, >>>>>> Andrew >>>>>> >>>>>>> On Thu, Sep 27, 2018 at 5:22 PM Qing Lan <lanking...@live.com> >>>>>> wrote: >>>>>> >>>>>>> I would like to loop this back a layer. Current, there is a >>>>> discussion in >>>>>>> the MXNet Scala community on the ways to implement the Java >>> APIs. >>>>> Currently >>>>>>> there are two thoughts: >>>>>>> >>>>>>> 1. Make Scala Java Friendly (Create Java compatible methods in >>>>> the Scala >>>>>>> Class. such as NDArray with Java compatible constructor) >>>>>>> 2. Make Java friendly wrappers in Scala (Andrew's explanation >>>>> below) >>>>>>> >>>>>>> The first approach require minimum input from our side to >>>>> implement >>>>>>> however bring user a bunch of useless api they may not want to >>>>> use. It also >>>>>>> makes Scala package heavier. The good thing is these two >>> packages >>>>> require >>>>>>> minimum maintenance cost. As a tradeoff, if any time in the >>>>> future we want >>>>>>> to make Java big (make Java as the primary language supported by >>>>> MXNet), >>>>>>> then the migration from Scala to Java will be harmful. Spark >>>>> consider this >>>>>>> carefully and decide not to change much on their Scala code base >>>>> to make it >>>>>>> more Java. >>>>>>> >>>>>>> The second approach will make unique NDArray, Shape, Context and >>>>> more. The >>>>>>> good thing about this is we can always holds a version control >>> on >>>>> Java. >>>>>>> Some breaking changes on Scala may not influence much on Java. >>> It >>>>> did the >>>>>>> best way to decouple the module and good for us to build unique >>>>> pipeline >>>>>>> for Java. The bad thing with this design is the maintenance cost >>>>> as we need >>>>>>> to keep two code bases, but it also make Java side easy to >>> change >>>>> to make >>>>>>> it better compatible with users. >>>>>>> >>>>>>> Thanks, >>>>>>> Qing >>>>>>> >>>>>>> On 9/27/18, 3:25 PM, "Andrew Ayres" <andrew.f.ay...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Currently, we're working to implement a new Java API and >>>>> would like >>>>>>> some >>>>>>> feedback from the community on an implementation detail. In >>>>> short, the >>>>>>> new >>>>>>> Java API will use the existing Scala API (in a manner >>> similar >>>>> to how >>>>>>> the >>>>>>> current Clojure API works). This basically means that we're >>>>> making Java >>>>>>> friendly wrappers to call the existing Scala API. >>>>>>> >>>>>>> The feedback we're looking for is on the implementation of >>>>> NDArray. >>>>>>> Scala's >>>>>>> NDArray has a significant amount of code which is generated >>>>> via macros >>>>>>> and >>>>>>> we've got two viable paths to move forward: >>>>>>> >>>>>>> 1.) Change the macro to generate Java friendly methods - To >>>>> do this >>>>>>> we'll >>>>>>> modify the macro so that the generated methods won't have >>>>>>> default/optional >>>>>>> arguments. There may also have to be some changes to >>>>> parameter types to >>>>>>> make them Java friendly. The big advantage here is that >>>>> ongoing >>>>>>> maintenance >>>>>>> will easier. The disadvantages are that we'll be changing >>> the >>>>> existing >>>>>>> Scala NDArray Infer API (it's marked experimental) and Scala >>>>> users will >>>>>>> lose the ability to use the default and optional arguments. >>>>>>> >>>>>>> 2.) Leave the existing macro in place and add another which >>>>> generates a >>>>>>> Java friendly version - The biggest issue here is that we'll >>>>> be >>>>>>> doubling >>>>>>> the number of macros that we've got to maintain. It'll >>> become >>>>> even more >>>>>>> overhead once we start expanding the Java API with more >>>>> classes that >>>>>>> use >>>>>>> generated code like this. The advantages are that the >>>>> existing Scala >>>>>>> NDArray Infer API would remain unchanged for Scala users and >>>>> that the >>>>>>> new >>>>>>> macro could be optimized to give the best possible >>> experience >>>>> to the >>>>>>> Java >>>>>>> API. >>>>>>> >>>>>>> Thanks, >>>>>>> Andrew >>>>> >>>>> >>>>> >>>>> -- >>>>> Yizhi Liu >>>>> DMLC member >>>>> Amazon Web Services >>>>> Vancouver, Canada > > > > -- > Yizhi Liu > DMLC member > Amazon Web Services > Vancouver, Canada
