+1
--
Hyunsik Choi
On Thu, Jan 5, 2012 at 8:57 PM, Sebastian Schelter s...@apache.org 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,
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
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
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
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
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
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:comment-tabpanelfocusedCommentId=13182721#comment-13182721
]
Jakob Homan commented on GIRAPH-122:
yep, looks like I could.
Roll
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}
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
[
https://issues.apache.org/jira/browse/GIRAPH-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182749#comment-13182749
]
Hudson commented on GIRAPH-122:
---
Integrated in Giraph-trunk-Commit #63 (See
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,
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
Yes, what is you say is completely reasonable, you convinced me :)
On Mon, Jan 9, 2012 at 11:28 PM, Avery Ching ach...@apache.org 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
In my opinion that means reducing to a single message or none at all.
CA 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
15 matches
Mail list logo
