giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Presta <>
Subject Re: LongDoubleFloatDoubleVertex
Date Thu, 28 Feb 2013 18:12:43 GMT
Hi Gianmarco,

Yes, there will be more efficient implementations.
In the redesign I'm working on (GIRAPH-528), there will be only one Vertex
class and edge storage is delegated to a VertexEdges class.
So far I'm adding some generic implementations (ByteArrayEdges,
ArrayListEdges, HashMapEdges) that work for all types, and some optimized
ones (LongDoubleArrayEdges, LongNullArrayEdges).

Do you specifically need edge values to be float while the other types are
It seems to me it would make sense to change RandomWalkVertex to use
double edge values instead, and avoid code duplication (i.e. adding a
LongFloatArrayEdges that's basically the same). We're not Trove after all.
Makes sense?

Thanks for the feedback,


On 2/28/13 1:54 AM, "Gianmarco De Francisci Morales" <>

>Maybe the specific implementation can be thrown away, but personally I
>very strongly for the need of a good LongDoubleFloatDouble vertex.
>It's the base for any serious random walk algorithm.
>I would call for a refactoring rather than a removal.
>Just my 2c.
>On Thu, Feb 28, 2013 at 7:54 AM, Alessandro Presta
>> Hi all,
>> Does anyone feel strongly for LongDoubleFloatDoubleVertex?
>> Reasons why I think it should be removed:
>>   1.  Right now it's incorrect (returns target vertex id as edge value).
>>   2.  Iteration will always be inefficient, since the underlying Mahout
>> open-addressing hash map implementation doesn't provide iterators. It
>> provides a way to copy the keys and values to external arrays/lists.
>>   3.  It's the only reason why we have Mahout as a dependency.
>> I think we should strive to provide model implementations that are
>> and/or extremely efficient. This one satisfies neither.
>> Thanks,
>> Alessandro

View raw message