systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dusenberr...@gmail.com
Subject Re: [PROPOSAL] R4ML Integration with SystemML
Date Sat, 23 Sep 2017 01:24:24 GMT
Adding an R interface to SystemML would be great.  I would suggest, in agreement with others
here, that the MLContext API be exposed in the R4ML package so that users *could* run arbitrary
DML code from R.  Past that, I wouldn't worry about making the rest exactly compatible with
mllearn at this point.  All languages, and their associated communities, have different approaches
to libraries, so it would make sense that there may be pieces that are specific to a certain
language.

-Mike

--

Mike Dusenberry
GitHub: github.com/dusenberrymw
LinkedIn: linkedin.com/in/mikedusenberry

Sent from my iPhone.


On Sep 22, 2017, at 3:47 PM, Deron Eriksson <deroneriksson@gmail.com> wrote:

>> 
>>>> So I was thinking is it absolutely must have to sync between api?
>> 
>> Soft-yes, we should try our best to do so.
>> 
> 
> There are many benefits both for SystemML users and developers to having
> the APIs be as consistent as possible. Based on user feedback, I know
> Niketan and Glenn did a lot of work recently to make the Python MLContext
> API much more consistent with the Java/Scala MLContext API. I think there
> is an expectation from SystemML users that code that utilizes one API will
> act in a similar fashion with as few modifications as possible if migrated
> to a different language.
> 
> As an example of a benefit to SystemML developers, if an R MLContext API is
> consistent with the Scala and Python APIs, an R tab can be added to
> http://apache.github.io/systemml/spark-mlcontext-programming-guide.html and
> most of the MLContext documentation can be reused across the different
> languages. This greatly simplifies the creation and maintenance of
> documentation, which is very important with a project as large as SystemML.
> In addition, consistency across MLContext APIs in different languages
> simplifies code maintenance since a developer familiar with the API
> features of one language can probably work without too much difficulty on
> one of the other language APIs in the project. This would not be the case
> if the APIs were significantly divergent.
> 
> Deron

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message