The thinking was to abstract away the intermediate graph that we actually
filter on, because this is a fairly common usage pattern (you want to
filter the original graph, but based on some property you need to compute).

I agree it's not a major change, though.


On Mon, Dec 16, 2013 at 11:29 PM, Ankur Dave <notifications@github.com>wrote:

> In graph/src/main/scala/org/apache/spark/graph/GraphOps.scala:
>
> > +   * changing the vertex and edge values in your program. For example, we could remove the vertices
> > +   * in a graph with 0 outdegree
> > +   *
> > +   * {{{
> > +   * graph.filter(
> > +   *   graph => {
> > +   *     val degrees: VertexSetRDD[Int] = graph.outDegrees
> > +   *     graph.outerJoinVertices(degrees) {(vid, data, deg) => deg.getOrElse(0)}
> > +   *   },
> > +   *   vpred = (vid: Vid, deg:Int) => deg > 0
> > +   * )
> > +   * }}}
> > +   *
> > +   */
> > +  def filter[VD2: ClassManifest, ED2: ClassManifest](
> > +      preprocess: Graph[VD, ED] => Graph[VD2, ED2],
>
> Oh, I guess the point of the function is to do the three operations
> (preprocess, subgraph, and mask) all in one. Considering that you have to
> pass in all the arguments to those functions as well, though, I wonder
> whether this would make user code more understandable.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/amplab/graphx/pull/48/files#r8393978>
> .
>