spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Owen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SPARK-14408) Is RDD.treeAggregate implemented correctly?
Date Tue, 05 Apr 2016 20:46:25 GMT

    [ https://issues.apache.org/jira/browse/SPARK-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227110#comment-15227110
] 

Sean Owen commented on SPARK-14408:
-----------------------------------

Yeah it's right-er at least. There's a test for foldByKey with a mutable type: "foldByKey
with mutable result type", though maybe it could be tweaked to use multiple partitions explicitly.
I suppose you could assert this explicitly in the docs since apparently it's tested for.

> Is RDD.treeAggregate implemented correctly?
> -------------------------------------------
>
>                 Key: SPARK-14408
>                 URL: https://issues.apache.org/jira/browse/SPARK-14408
>             Project: Spark
>          Issue Type: Question
>          Components: Spark Core
>            Reporter: Joseph K. Bradley
>
> **Issue**
> In MLlib, we have assumed that {{RDD.treeAggregate}} allows the {{seqOp}} and {{combOp}}
functions to modify and return their first argument, just like {{RDD.aggregate}}.  However,
it is not documented that way.
> I started to add docs to this effect, but then noticed that {{treeAggregate}} uses {{reduceByKey}}
and {{reduce}} in its implementation, neither of which technically allows the seq/combOps
to modify and return their first arguments.
> **Question**: Is the implementation safe, or does it need to be updated?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org


Mime
View raw message