commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claudio Squarcella <>
Subject Re: [Graph] On graph weight type(s)
Date Wed, 14 Dec 2011 09:36:48 GMT

>> trying to put it all together (thanks James, Matthew):
>>   * Weighted<W>  is fully generic without restrictions on the type of
>>    weight W
>>   * different properties of weights are specified with interfaces: e.g.
>>    Summable, HasZero, Comparable...
>>   * each algorithm requires the weights to implement one or more of the
>>    above interfaces based on needs, and only works with related methods
>>    abstracting from the actual type of weight. For example sum(W
>>    weight) for Summable.
> this is interesting - at a first read looked like an over engineered
> layer, but it perfectly model the weight domain... can you provide a
> patch containing such classes and see them in action in current
> implemented algos?

of course I can, hopefully later this week.
And you're right, it sounds over-engineered. But it also gives much more 
freedom to the end user, so maybe in the future someone could say 
"thanks" ;)

>> Now, IFF you like that... what shall we do with Double, Integer, etc?
> uhm I think we can get rid of them, this is something depending on the
> domain in which algorithms are applied.

Well, ideally the user should be able to use seamlessly all the wrappers 
for primitive number types: i.e., a graph with edges that implement 
Weighted<Double> should just work the way it is as an input for 
Dijkstra. But of course Double & co are "legacy" that have nothing to do 
with our fresh interfaces (Summable & co). So there are at least two 

  * The user has to wrap primitive types into classes that implement the
    appropriate interfaces, in order to "speak the same language" of the
    algorithm implementations. Some of these classes could of course be
    provided in the library (e.g. DoubleWeight, IntegerWeight).
  * The algorithms offer additional signatures for the same method that
    are "legacy-compatible" to some extent (e.g. only for Double and
    Integer), and then take care of the conversion internally.

I would go for the second one, because 'ignorance is bliss' for the user :)



> Looking forward to hear from you soon!
> -Simo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Claudio Squarcella
PhD student at Roma Tre University
E-mail address:
Phone: +39-06-57333215
Fax: +39-06-57333612

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message