I agree that C&A doesn't require it, however, I can't think of why I
would want to use a combiner to expand the number of messages. Can you?
Avery
On 1/9/12 3:57 PM, Jakob Homan wrote:
In my opinion that means reducing to a single message or none at all.
C&A doesn't require this, however. H
that was my point as well, max and sum are typical examples. it would
make it more expressive and powerful, as it extends the one or null
model, and possibly more elegant. useful is a different story and i
wouldn't know how to measure at this point (which was the convincing
part of avery's point).
> In my opinion that means reducing to a single message or none at all.
C&A doesn't require this, however. Hadoop's combiner interface, for
instance, doesn't require a single or no value to be returned; it has
the same interface as a reducer, zero or more values. Would adapting
the semantics of
Yes, what is you say is completely reasonable, you convinced me :)
On Mon, Jan 9, 2012 at 11:28 PM, Avery Ching wrote:
> Combiners should be commutative and associative. In my opinion that means
> reducing to a single message or none at all. Can you think of a case when
> more than 1 message sh
Combiners should be commutative and associative. In my opinion that
means reducing to a single message or none at all. Can you think of a
case when more than 1 message should be returned from a combiner? I
know that returning null isn't preferable in general, but I think that
functionality (
To clarify, I was not discussing the possibility for combine to return
null. I see why it would be useful, given that combine returns M,
there's no other way to let combiner ask not to send any message,
although i agree with Jakob, I also believe returning null should be
avoided but only used, roug
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182749#comment-13182749
]
Hudson commented on GIRAPH-122:
---
Integrated in Giraph-trunk-Commit #63 (See
[https://builds
I'm not a big fan of returning null as it adds extra complexity to the
calling code (null checks, or not, since people usually will forget
them). Avery is correct that combiners are application specific. Is
it conceivable that one would want to write a combiner that returned
something for an inpu
The javadoc for VertexCombiner#combine() is
/**
* Combines message values for a particular vertex index.
*
* @param vertexIndex Index of the vertex getting these messages
* @param msgList List of the messages to be combined
* @return Message that is combined from {@link MsgList}
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182721#comment-13182721
]
Jakob Homan commented on GIRAPH-122:
yep, looks like I could.
> Rol
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182688#comment-13182688
]
Claudio Martella commented on GIRAPH-122:
-
There's also a reference in CHANGELOG.
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Homan updated GIRAPH-122:
---
Attachment: GIRAPH-122.patch
Quick one line patch. Searched for other references to 0.7, but didn't
Roll version back to 0.1
Key: GIRAPH-122
URL: https://issues.apache.org/jira/browse/GIRAPH-122
Project: Giraph
Issue Type: Improvement
Reporter: Jakob Homan
Assignee: Jakob Homan
Per the vot
Dear podling,
This email was sent by an automated system on behalf of the Apache Incubator
PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.
The board meeting is scheduled for Wed, 18 January 2012, 10:00:00 PST. The
report
for your podling will
Hi Sebastian,
yes, that was my point, I agree completely with you.
Fixing my test was not the issue, my question was whether we want to
define explicitly the semantics of this scenario.
Personally, I believe the combiner should be ready to receive 0
messages, as it's the case of BasicVertex::initi
I think we currently implicitly assume that there is at least one
element in the Iterable passed to the combiner. The messaging code only
invokes the combiner only if at least one message for the target vertex
has been sent.
However, we should not rely on implicit implementation details but
explic
Hello list,
for GIRAPH-45 I'm touching the incoming messages and hit an
interesting problem with the combiner semantics.
currently, my code fails testBspCombiner for the following reason:
SimpleSumCombiner::compute() returns a value even if there are no
messages in the iterator (in this case it r
Hi Eugenia,
can you share some details about your experiments on this list? Your
report mentions some design decisions you were unhappy with. Would be a
interesting to know what these are, so we can improve them!
Best,
Sebastian
On 08.01.2012 03:40, Eugenia Gabrielova wrote:
> Hello,
>
> My n
+1
--
Hyunsik Choi
On Thu, Jan 5, 2012 at 8:57 PM, Sebastian Schelter wrote:
> +1 from me too, as Jake already said: release early, release often.
>
>
> On 04.01.2012 23:07, Mattmann, Chris A (388J) wrote:
> > Super +1, thanks for pushing this Jakob.
> >
> > Cheers,
> > Chris
> >
> > On Jan 4,
19 matches
Mail list logo
