systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Boehm" <mbo...@us.ibm.com>
Subject Discussion SYSTEMML-593 MLContext Resign
Date Sun, 03 Apr 2016 04:34:37 GMT


thanks Deron for initiating the discussion around the rework of our
MLContext API (https://issues.apache.org/jira/browse/SYSTEMML-593). Here
are a couple of thoughts:

(1) Simplicity: Given that the primary usecase of MLContext calls a script
exactly once, I'm wondering if the separation into Script, ScriptFactory,
ScriptExecutor and MLContext adds unnecessary complexity by requiring more
code to setup. It would be great to see old vs new examples side by side.
Also rather than introducing another exception class, couldn't we just
reuse DMLException by making it an uncaught exception?

(2) Compilation: ScriptExecutor would also be yet another replicate of our
compilation chain (beside DMLScript, Debugger, JMLC, MLContext). Please,
keep in mind that we are about to consolidate this, centralizing these
calls via a configurable compilation chain because it really becomes a
maintenance nightmare (as recently seen when we reworked our thread-local
configuration management).

(3) Data Representation / Converters: Making data conversions and
input/output handling easier is certainly useful. However, isn't this new
class hierarchy redundant to our already existing hierarchy of Data,
MatrixObject, FrameObject, and ScalarObject?

(4) Consolidating MLContext and JMLC: This is a good idea since MLContext
is anyway "derived" from JMLC and both rely on the same concepts for
input/output handling and program modification (see JMLCUtils). Down the
road I would like to see a convergence to something like Script and
PreparedScript in the spirit of JDBC's Statement and PreparedStatement
(btw, that's how we created JMLC). Let's keep in mind that there are
already a number of users working against both MLContext and JMLC, so we
should support them separately until our major 1.0 release.


Regards,
Matthias

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