jvm side for that our self.
>>>>>>>>>>>>> A good example of JavaCPP and Scala usage is Apache Mahout
>>> [1].
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if we don't use JavaCPP, the JNI layer
; >> >>> >> >> the major sources of bugs, especially with two languages
> which
> >> >> are
> >> >> >>> >> >> naturally interactive (OK, Calling Scala from Java might
> need
> >> >> some
> >
rovide C++ & C APIs of MxNet in
>> two
>> >> >>> >> separated
>> >> >>> >> >> packages.
>> >> >>> >> >>
>> >> >>> >> >> About dependency problem, when you say "As far a
isadvantage that the Java API would force Scala as a
> dependency
> >> onto
> >> >>> >> the
> >> >>> >> >> java users.", would you please give a concrete example causing
> >> >>> critical
> >
;>> >> >> Nan
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Wed, Aug 16, 2017 at 8:19 AM, YiZhi Liu <javeli...@gmail.com>
>> >>> wrote:
>> >>> >&g
f we build the Java API from the very beginning, i.e. the JNI
> part,
> >>> >> >>> we have to rewrite the codes for training, predict, inferShape,
> etc.
> >>> >> >>> It would be too heavy to maintain a totally new front language.
> >>&
; For a library it is always a great advantage if it doesn't have
> many
> > >>> > dependencies, or zero dependencies. In our case it could be quite
> > >>> > realistic to have a thin wrapper around the C API without needing
> any
> > >>> >
> >
> >> >>> > the approach which is taken by Spark is described here [1].
> >> >>> >
> >> >>> > As far as I see this has the great disadvantage that the Java API
> >> >>> > would force Scala as a depende
't have many
>> >>> > dependencies, or zero dependencies. In our case it could be quite
>> >>> > realistic to have a thin wrapper around the C API without needing any
>> >>> > other dependencies (or only dependencies which can't be avoided).
&g
dependencies (or only dependencies which can't be avoided).
> >>> >
> >>> > The JNI layer could easily be shared between the Java and Scala API.
> >>> > As far as I understand is the JNI layer in the Scala API anyway
> >>> > private and a
change to it wouldn't require that the public part of
> >> > the Scala API is changed.
> >> >
> >> > What do you think?
> >> >
> >> > Jörn
> >> >
> >> > [1] https://cwiki.apache.org/confluence/display/SPA
o it wouldn't require that the public part of
>>> > the Scala API is changed.
>>> >
>>> > What do you think?
>>> >
>>> > Jörn
>>> >
>>> > [1] https://cwiki.apache.org/confluence/display/SPARK/Java+API+Internals
>&g
part of
> > > the Scala API is changed.
> > >
> > > What do you think?
> > >
> > > Jörn
> > >
> > > [1]
> https://cwiki.apache.org/confluence/display/SPARK/Java+API+Internals
> > >
> > > On Wed, Aug 16, 2017 at 3
PI as a wrapper of Scala API, re-use most of
> >> the procedures. Referring to the Java API in Apache Spark.
> >>
> >> 2017-08-16 18:21 GMT+08:00 Joern Kottmann <jo...@apache.org>:
> >>> Hello all,
> >>>
> >>> I would like to propose t
, YiZhi Liu <javeli...@gmail.com> wrote:
>>> Hi Joern,
>>>
>>> I suggest to build Java API as a wrapper of Scala API, re-use most of
>>> the procedures. Referring to the Java API in Apache Spark.
>>>
>>> 2017-08-16 18:21 GMT+08:00 Joern Ko
> Hi Joern,
>>
>> I suggest to build Java API as a wrapper of Scala API, re-use most of
>> the procedures. Referring to the Java API in Apache Spark.
>>
>> 2017-08-16 18:21 GMT+08:00 Joern Kottmann <jo...@apache.org>:
>>> Hello all,
>>>
>>>
uggest to build Java API as a wrapper of Scala API, re-use most of
> the procedures. Referring to the Java API in Apache Spark.
>
> 2017-08-16 18:21 GMT+08:00 Joern Kottmann <jo...@apache.org>:
>> Hello all,
>>
>> I would like to propose the addition of a Java API t
Hi Joern,
I suggest to build Java API as a wrapper of Scala API, re-use most of
the procedures. Referring to the Java API in Apache Spark.
2017-08-16 18:21 GMT+08:00 Joern Kottmann <jo...@apache.org>:
> Hello all,
>
> I would like to propose the addition of a Java API to MXNet
Hello all,
I would like to propose the addition of a Java API to MXNet.
There has been some previous work done for the Scala API, and it makes
sense to at least share the JNI layer between the two.
The Java API probably should be aligned with the Python API (and
others which exist already
19 matches
Mail list logo
