[
https://issues.apache.org/jira/browse/MAHOUT-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002651#comment-14002651
]
Dmitriy Lyubimov commented on MAHOUT-1529:
------------------------------------------
ok i started nudging this a bit forward, did a couple of fairly drastical
refactoring, moving api parts to math-scala. math-scala should compile .
Decompositions are moved too.
Things left include moving package-level routines requiring implicit context;
fixing spark and spark-shell modules; moving tests where appropriate.
With tests. a little conundrum is such that we don't have a "local" engine --
we would use "Spark local" for that, i.e. some concrete engine. So even though
decomposition code now completely lives in math-scala with no spark
dependencies, it looks like its tests will still have to live in spark module,
where unit-testing in local spark mode is defined. It kinda makes sense, since
we probably will want to run MathSuite separately for each engine we add; but
is a bit weird since it keeps something like ssvd() and its engine-specific
tests apart.
> Finalize abstraction of distributed logical plans from backend operations
> -------------------------------------------------------------------------
>
> Key: MAHOUT-1529
> URL: https://issues.apache.org/jira/browse/MAHOUT-1529
> Project: Mahout
> Issue Type: Improvement
> Reporter: Dmitriy Lyubimov
> Fix For: 1.0
>
>
> We have a few situations when algorithm-facing API has Spark dependencies
> creeping in.
> In particular, we know of the following cases:
> -(1) checkpoint() accepts Spark constant StorageLevel directly;-
> (2) certain things in CheckpointedDRM;
> (3) drmParallelize etc. routines in the "drm" and "sparkbindings" package.
> (5) drmBroadcast returns a Spark-specific Broadcast object
> *Current tracker:*
> https://github.com/dlyubimov/mahout-commits/tree/MAHOUT-1529.
> *Pull requests are welcome*.
--
This message was sent by Atlassian JIRA
(v6.2#6252)