Qing, thanks for a great summary.
The discussion(offline and much of it on Slack) was whether to add new APIs
for Java that removed *Option* from parameters of the existing Scala APIs
and add builders where necessary or refactor Scala APIs to achieve this. My
answer and response was based on that
Here I have done a summary about the opinion most people holds:
Naveen & Yizhi thoughts in a technical way:
Agreement: -1 for total Java conversion (build all wrappers from Scala
to Java)
Yizhi: A hybrid solution may works the best (Build only necessary Java
class for Java users
+1 to this suggestion. Voting should be seen as a last resort to
resolve differences in the community. Perhaps a small POC of both
approaches (or maybe others as well) might help the community discuss
options in a more concrete way. Sometimes is very difficult to "see"
the differences between
Maybe we can take a step back and rather look at how we would like our
users and mxnet developers to use the API. Imagine like a mock or pseudo
code where we write a few examples with the "perfect" Java API. After that,
we think about the technical implementation details and how it can be done
(I
Yes agreement and disagreement stay at technical level only:)
Back to the problem, they are unnecessary but good in terms of,
1. Still not good for java users to write 3 nulls in a function call with 5
or 4 args
2. Every function call with a “tail” null for arg “out”. I would say, makes
it seems
Ah! we agree on something :) lets get more opinions, I am happy to go with
it.
On Sat, Sep 29, 2018 at 10:40 PM YiZhi Liu wrote:
> Also sometimes people may not be at the same page when talking about option
> #2. What I insist is the builder classes for each operator. Otherwise I
> actually
IMO, its unnecessary. this is only my opinion and you are free to disagree.
With more opinions one or some of us will have to commit to the majority of
the opinion.
On Sat, Sep 29, 2018 at 10:35 PM YiZhi Liu wrote:
> No you haven't answered my question "Since you agree to have 30+
> operators
I am not sure what makes you think that I am suggesting we should not fix
it. I am pointing out that many of those are incorrectly optional so don't
take that into consideration to make a decision whether we need builders
for all.
On Sat, Sep 29, 2018 at 10:15 PM YiZhi Liu wrote:
> And if we
Also sometimes people may not be at the same page when talking about option
#2. What I insist is the builder classes for each operator. Otherwise I
actually more support Naveen’s approach - not to totally separate java and
scala objects.
On Sat, Sep 29, 2018 at 7:35 PM YiZhi Liu wrote:
> No you
I think we have had enough of an debate between the two of us and I have
already listed my reasons, I will stop here and see what others say given
my reasoning.
-1 to #2)
Also, by lecture I meant to say "I don't want to list all the problems
with unnecessary complications and talk about how to
And if we find incorrect declaration, we fix it, not simply assuming
many of them also has problem and we cannot rely on them - otherwise
the type-safe APIs in Scala also does not make sense.
On Sat, Sep 29, 2018 at 7:10 PM YiZhi Liu wrote:
>
> It also makes sense to me if we have it under
Well, I am not sure(I don't think) we need Builder for every API in
NDArray. For APIs that take long list of parameters, I agree to add Builder.
Look at the API distribution based on number of arguments here:
https://gist.github.com/nswamy/2dea72e514cc7bfc675f68aef9fe78bb
about 30 APIs have 7 or
Some of my comments inline:
> Why can we not create the builder just for these APIs( which we discussed),
> why is it necessary to add 200 Apis
It is about unified user-experience. And we get rid of annoying extra
"out=null" in every operator.
> Are you suggesting to create builder for each and
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
Moreover, regarding "add 200+ APIs" - this was exactly what we did for
type-safe APIs in Scala, we have NDArray/Symbol.BatchNorm and
NDArray/Symbol.api.BatchNorm - why did we decide to do that? Because
we thought type-safe could provide better user-experience. Given the
example I listed above, I
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
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] =
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 wrote:
> +1 on option #2
>
> In the case of minimizing the the overhead for code maintenance, I wanted
> to suggest the option of
+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
+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
Thanks Chris for your excellent explanation! Personally I like the way we
separate the world that Scala and Java shares so Java developers don't have to
think of how to use "Scala" in order to write Java code. I think usability for
Java users and Scala users is the most important tasks we need
My $0.02 since I’m working with a lot of java and scala lately, including
the interaction between the two:
Please keep in mind the more complex dependency issues that will be
introduced by requiring Java users to now have to pull in a large scala
dependency base. In addition, a lot is Scala is
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
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
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
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
26 matches
Mail list logo
